At 10:08am -0400 5/8/03, Chuck Ebbert wrote:
> > I have no idea, what a 'typical processor' might look like. But the
>> thing most CPU seem to have in common is that they save two registers
>> either on the stack or into other registers that only exist for this
>> purpose (SRR on PPC).
>>
>> Once that has happened, the OS has the job to figure out where it's
>> stack (or equivalent) is located, *without* clobbering the registers.
>> Once that is done, it can save all the registern on the stack,
>> including SRR.
>
> On i386 the CPU automatically switches to the stack corresponding to
>the privilege level (PL) of the interrupt handler, then pushes the
>instruction pointer and flags onto that stack. It is theoretically
>possible to write unprivileged interrupt handlers by using conforming
>code segments, in which case a stack switch will not occur, but such a
>handler cannot touch anything but registers and stack so it's not very
>useful.
In particular, the interrupt stack is the kernel stack of the current
task. This is (in part) what leads to stack overflows. If the current
task is running in the kernel, using a significant hunk of its stack,
an interrupt is limited to the balance of that stack. And if that
interrupt triggers a soft irq that runs, say, a network stack, and
that softirq handler in turn gets interrupted, we've got,
effectively, three processes sharing the stack. And of course hard
interrupts can be nested, so it's pretty damn difficult to specify a
safe upper limit for stack usage.
-- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:28 EST