Re: top stack (l)users for 2.5.69

[Roland Dreier <roland@topspin.com>]

    Roland> Right.  Now think about where the kernel stack for the
    Roland> process that is sleeping in the kernel is kept.

    Richard> It's the kernel, of course. The scheduler runs in the
    Richard> kernel under the kernel stack, with the kernel data. It
    Richard> has nothing to do with the original user once the user
    Richard> sleeps. The user's context was saved, the kernel was set
    Richard> up, and the kernel will schedule other tasks until the
    Richard> sleep time or the sleep_on even is complete.  At that
    Richard> time, (or thereafter), the kernel will schedule the
    Richard> previously sleeping task, its context will be restored,
    Richard> and it continues execution.

    Richard> The context of a task (see entry.S) is completely defined
    Richard> by its registers, including the hidden part of the
    Richard> segments (selectors) that define priviledge.

I'll try one more time.  Let's say a user process makes a system call
and enters the kernel.  That system call goes through a few function
calls in the kernel (which each push something on the kernel stack for
that process).  Finally, the kernel has to sleep to sleep to service
the system call (let's say it's a blocking read() waiting for some
data to arrive on a socket).

OK, now the scheduler runs, and another user process starts and makes
its own system call, which also goes to sleep.

Now say the data the original process was waiting for arrives.  The
scheduler wakes up that process, which is in the kernel, and it
finishes servicing the read.  This means it now returns through the
chain of kernel function calls before returing to user space.  Each
return in kernel space has to pop some stuff off the stack, and it
better not get mixed up with the second process's kernel stack.

That's (one reason) why each process needs its own kernel stack.

 - Roland