[lkml]   [2003]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: top stack (l)users for 2.5.69

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.104 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site