From: suthambhara nagaraj <suthambhara@gmail.com>
To: "Dhiman, Gaurav" <gaurav.dhiman@ca.com>
Cc: main kernel <linux-kernel@vger.kernel.org>,
kernel <kernelnewbies@nl.linux.org>
Subject: Re: Kernel stack
Date: Tue, 12 Oct 2004 12:21:37 +0530 [thread overview]
Message-ID: <46561a790410112351942e735@mail.gmail.com> (raw)
In-Reply-To: <577528CFDFEFA643B3324B88812B57FE3055B9@inhyms21.ca.com>
Hi,
The problem is each process does not have a TSS of its own.Only one
TSSper processor is present and the process dependant features (Like
esp) are stored
in another structure( struct thread_struct ).A kernel stack of size 8k
(By default)
is actully shared by processes running on a processor. There is a func named
load_tss (or something similiar) which loads the TSS from the
thread_struct structure during task switch .
A Process does not have an SS entry in its thread_struct but only an
esp (and esp0) entry. This made me believe that the stack base is the
same.
Correct me
Regards
On Tue, 12 Oct 2004 11:55:24 +0530, Dhiman, Gaurav <gaurav.dhiman@ca.com> wrote:
>
> > I have not understood how the common kernel stack in the
> > init_thread_union(2.6 ,init_task_union in case of 2.4) works for all
> > the processes which run on the same processor
>
> As far as I know, Kernel do not have any common stack for all the
> processes running over it. Whenever we enter the kernel mode thru system
> calls, we go thru system gate or descriptor (0x80 entry) in IDT. This
> entry contains the index of the descriptor in GDT (normally it points to
> Kernel CS Segment Descriptor in GDT) and the offset (pointer) to the
> code to be executed in kernel mode (which is system_call() function in
> Kernel).
>
> Now the descriptor entry in GDT pointed out by the system gate entry in
> IDT, contains 2 bit field known as DPL (Desired Privelege Level). If
> this DPL is less than the CPL (Current Prevelege Level) of CPU then CPU
> switches to the process specific kernel stack segement by refferring the
> TSS of current running process. This stack switch is automatic by CPUand
> there is no assembly intruction required for it.
>
> This stack switch is done at the time when we enter from user space to
> the kernel space, this is done because we can not trust and share the
> user process stack (stack used by user process in user mode). That is
> why every process has atleast two and can even have four stacks. In each
> process, stack for every CPU level (ring level) is defined. So whenever
> the process runs in user mode (ring 3), its user mode stack is used, but
> when it enters the kernel mode (ring 0) its stack is switched to the
> kernel stack of that process. All the stacks of a process for different
> levels of CPU are tracked thru TSS defined for that process.
>
> To read more on IDT, GDT, TSS and System Calls invocation, refer to the
> Intels System Programmer's Guide. Her is the Link:
> ftp://download.intel.com/design/PentiumII/manuals/24319202.pdf
>
> Correct me if I am wrong somewhere.
>
> Cheers !!
> Gaurav
>
>
>
>
> -----Original Message-----
> From: kernelnewbies-bounce@nl.linux.org
> [mailto:kernelnewbies-bounce@nl.linux.org] On Behalf Of suthambhara
> nagaraj
> Sent: Tuesday, October 12, 2004 10:31 AM
> To: kernel
> Subject: Kernel stack
>
> Hi all,
>
> I have not understood how the common kernel stack in the
> init_thread_union(2.6 ,init_task_union in case of 2.4) works for all
> the processes which run on the same processor. The scheduling is round
> robin and yet the things on the stack (saved during SAVE_ALL) have to
> be maintained after a switch without them getting erased. I am
> familiar with only the i386 arch implementation.
>
> Please help
>
> regards,
> Suthambhara
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
>
next parent reply other threads:[~2004-10-12 6:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <577528CFDFEFA643B3324B88812B57FE3055B9@inhyms21.ca.com>
2004-10-12 6:51 ` suthambhara nagaraj [this message]
2004-10-12 9:41 ` Kernel stack Jan Hudec
2004-10-12 10:05 ` aq
2004-10-12 10:27 ` Jan Hudec
2004-10-12 12:30 ` aq
2004-10-12 13:11 ` Jan Hudec
2004-10-12 14:30 ` Jon Masters
2004-10-12 14:31 ` Jan Hudec
2004-10-13 5:03 Thekkedath, Gopakumar
-- strict thread matches above, loose matches on Subject: below --
2004-10-13 4:35 Dhiman, Gaurav
2004-10-14 19:31 ` Denis Vlasenko
2004-10-12 7:51 Thekkedath, Gopakumar
2004-10-12 6:15 kernel stack suthambhara nagaraj
2004-10-12 11:09 ` Neil Horman
2004-10-13 3:29 ` suthambhara nagaraj
2004-10-14 3:15 ` suthambhara nagaraj
2001-09-11 15:53 Kernel stack Richard J Moore
2001-09-10 21:47 Raghava Raju
2001-09-10 21:57 ` Erik Mouw
2001-09-11 10:31 ` Emmanuel Varagnat
2001-09-11 12:15 ` Richard B. Johnson
2001-08-27 22:24 Raghava Raju
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46561a790410112351942e735@mail.gmail.com \
--to=suthambhara@gmail.com \
--cc=gaurav.dhiman@ca.com \
--cc=kernelnewbies@nl.linux.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox