Re: top stack (l)users for 2.5.69

[Timothy Miller <miller@techsource.com>]

Richard B. Johnson wrote:
> 
> In protected mode, the kernel stack. And, regardless of implimentation
> details, there can only be one. It's the one whos stack-selector
> is being used by the CPU. So, in the case of Linux, with multiple
> kernel stacks (!?????), one for each process, whatever process is
> running in kernel mode (current) has it's SS active. It's the
> one that gets hit with the interrupt.

That's kinda what I figured.  I just didn't know if there was some 
(hardware) provision to do otherwise, or if there was some reason why 
the interrupt handler might immediately switch stacks, etc.

That is to say, some CPUs might have provision for a stack pointer to be 
associated with each interrupt vector.

Secondly, given so many unknowns about what might already be on the 
current kernel stack, it might be generally safer to move the processor 
state (saved by the CPU on interrupt) from the current stack to some 
"interrupt stack" which may have a more predictable amount of free 
space.  (Then again, if the CPU is currently executing in user space, 
the kernel stack is probably completely empty.)

I realize that, however small, that would be an undesirable amount of 
overhead, but it occurs to me that someone might do that anyhow for 
stability reasons.  I could imagine some interrupts needing more than a 
trivial amount of stack space.  I'm assuming, for instance, that things 
like the IDE block driver would need to do things like PIO a sector 
to/from an old CDROM drive, look up the next scheduled I/O operation to 
perform, etc.