Re: top stack (l)users for 2.5.69

[Timothy Miller <miller@techsource.com>]

Richard B. Johnson wrote:
> On Wed, 7 May 2003, Roland Dreier wrote:
> 
> 
>>    Richard> The kernel stack, at least for ix86, is only one, set
>>    Richard> upon startup at 8192 bytes above a label called
>>    Richard> init_task_unit. The kernel must have a separate stack
>>    Richard> and, contrary to what I've been reading on this list, it
>>    Richard> can't have more kernel stacks than CPUs and, I don't see
>>    Richard> a separate stack allocated for different CPUs.
>>
>>This is total nonsense.  Please don't confuse matters by spreading
>>misinformation like this.  Every task has a separate (8K) kernel
>>stack.  Look at the implementation of do_fork() and in particular
>>alloc_task_struct().
>>
>>If there were only one kernel stack, what do you think would happen if
>>a process went to sleep in kernel code?
>>
>> - Roland
>>
> 
> 
> No, No. That is a process stack. Every process has it's own, entirely
> seperate stack. This stack is used only in user mode. The kernel has
> it's own stack. Every time you switch to kernel mode either by
> calling the kernel or by a hardware interrupt, the kernel's stack
> is used.
> 
> When a task sleeps, it sleeps in kernel mode. The kernel schedules
> other tasks until the sleeper has been satisfied either by time or
> by event.


I don't think this is quite accurate either.  I have been reading this 
thread, and putting that together with what makes sense to me, I gather 
that Linux uses the following stacks:

1) A variable sized user-space stack, one per process (maybe more for 
user-level threads?).  This is swappable.

2) One 8K kernel stack for each process.  This is used for situations 
such as when a user process makes a system call that then needs to use a 
stack.  This has to be separate from the user stack for two reasons:
    (a) If the user process borked the user stack pointer, the kernel 
still needs to have something valid.
    (b) The stack used by the kernel cannot be swappable.

3) One single interrupt stack for hardware interrupts.  I don't know how 
various CPU's deal with this, so either the CPU knows to use this for 
hardware interrupts, or the hardware interrupt starts using the current 
process's kernel stack then realizes this and switches over.


At the moment, I'm assuming that when the kernel is preempted, the stack 
switched to is one which is the kernel stack for some other process.