kernel stack

kernel stack

[suthambhara nagaraj]

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

Re: kernel stack

[Neil Horman]

suthambhara nagaraj wrote:
> 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
> 
There is no such thing as "the common kernel stack".  Each process 
(represented by a task_struct in the kernel) has its own private data 
space to be used as a kernel stack when that process traps into the 
kernel.  You can see where this per task_struct stack space is reserved 
in the definition of task_union.  init_[task|thread]_union just defines 
the first task union in the system.  Because of the way unions are laid 
out in memory, The kernel knows that when a process traps into kernel 
space, it just needs to round the current task pointer to the nearest 8k 
(prehaps 4k in 2.6) boundary, and thats the start of that processes 
kernel stack.  Thats how the SAVE_ALL command avoids trampling registers.

HTH
Neil
> regards,
> Suthambhara
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
/***************************************************
  *Neil Horman
  *Software Engineer
  *Red Hat, Inc.
  *nhorman@redhat.com
  *gpg keyid: 1024D / 0x92A74FA1
  *http://pgp.mit.edu
  ***************************************************/

Re: kernel stack

[suthambhara nagaraj]

Thanks Neil. I was an idiot to have overlooked  that.
Thanks once again

Regards
Suthambhara


On Tue, 12 Oct 2004 07:09:09 -0400, Neil Horman <nhorman@redhat.com> wrote:
> 
> 
> suthambhara nagaraj wrote:
> > 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
> > 
> There is no such thing as "the common kernel stack".  Each process
> (represented by a task_struct in the kernel) has its own private data
> space to be used as a kernel stack when that process traps into the
> kernel.  You can see where this per task_struct stack space is reserved
> in the definition of task_union.  init_[task|thread]_union just defines
> the first task union in the system.  Because of the way unions are laid
> out in memory, The kernel knows that when a process traps into kernel
> space, it just needs to round the current task pointer to the nearest 8k
> (prehaps 4k in 2.6) boundary, and thats the start of that processes
> kernel stack.  Thats how the SAVE_ALL command avoids trampling registers.
> 
> HTH
> Neil
> > regards,
> > Suthambhara
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> --
> /***************************************************
>  *Neil Horman
>  *Software Engineer
>  *Red Hat, Inc.
>  *nhorman@redhat.com
>  *gpg keyid: 1024D / 0x92A74FA1
>  *http://pgp.mit.edu
>  ***************************************************/
>

Re: kernel stack

[suthambhara nagaraj]

Hi all,

I went through the code of do_fork.
do_fork calls copy_process which in turn calls 
dup_task_struct .Here alloc_thread_info allocates the 
kernel stack for the process

Thanks all

Regards
Suthambhara


On Wed, 13 Oct 2004 08:59:14 +0530, suthambhara nagaraj
<suthambhara@gmail.com> wrote:
> Thanks Neil. I was an idiot to have overlooked  that.
> Thanks once again
> 
> Regards
> Suthambhara
> 
> 
> 
> 
> On Tue, 12 Oct 2004 07:09:09 -0400, Neil Horman <nhorman@redhat.com> wrote:
> >
> >
> > suthambhara nagaraj wrote:
> > > 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
> > >
> > There is no such thing as "the common kernel stack".  Each process
> > (represented by a task_struct in the kernel) has its own private data
> > space to be used as a kernel stack when that process traps into the
> > kernel.  You can see where this per task_struct stack space is reserved
> > in the definition of task_union.  init_[task|thread]_union just defines
> > the first task union in the system.  Because of the way unions are laid
> > out in memory, The kernel knows that when a process traps into kernel
> > space, it just needs to round the current task pointer to the nearest 8k
> > (prehaps 4k in 2.6) boundary, and thats the start of that processes
> > kernel stack.  Thats how the SAVE_ALL command avoids trampling registers.
> >
> > HTH
> > Neil
> > > regards,
> > > Suthambhara
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> >
> > --
> > /***************************************************
> >  *Neil Horman
> >  *Software Engineer
> >  *Red Hat, Inc.
> >  *nhorman@redhat.com
> >  *gpg keyid: 1024D / 0x92A74FA1
> >  *http://pgp.mit.edu
> >  ***************************************************/
> >
>

Re: Kernel stack

[Denis Vlasenko]

On Wednesday 13 October 2004 07:35, Dhiman, Gaurav wrote:
> Yes it definitely can happen (and I think this is the way to do it) that
> SS in process's TSS is initialized to the memory address just next to
> task_struct (as the kernel stack can grow downwards till this limit)

SS:0 points to 0x00000000 linear address. IOW: SSdescr.base == 0

> while the forking of a process and also sets the SP to the fixed offset
> from task_struct from where the kernel stack starts growing downwards
> (as you mentioned kernel stack starts from there). Now whenever this
> process will be scheduled by the scheduler or a process enters the
> kernel mode, CPU's SS and SP registers are re-set to the SS and SP
> elements in TSS of that process.

On task switch it is unnnecessary if SS does not really change (which
is happening 99.9% of the time). At user->kernel mode, yes, CPU
loads SS from TSS.ss field.

> At the time of scheduling, scheduler also change the TSS descriptor for
> that CPU on which the process is going to be scheduled. It changes this
> TSS descriptor in GDT to point to the TSS of the selected process.

There is no "TSS of the selected process". There is only one TSS per CPU.
(Intel didn't plan for this arrangement, but Linux nevertheless uses it).

Because of this, scheduler does not "change the TSS descriptor for
that CPU on which the process is going to be scheduled". It simply patches
some values in current CPU's TSS segment. This is way faster that executing
microcoded TSS change.

> Correct me if I am wrong.
>
> [overquoting snipped]
--
vda

RE: Kernel stack

[Thekkedath, Gopakumar]

>You discussed that kernel do not keep track of SS for process specific
>kernel stack as it always starts from fixed offset of task_struct, but
>does that mean, linux kernel do not make use of SS element in the TSS of
>process. I think the kernel can not by-pass the rules defined by
>processor. Processor expects the SS and SP elements to be right at the
>time of stack switching, so we need to initialize them to the right
>values while forking a process.

	Yes, the kernel cannot bypass the TSS entirely.

>I think kernel definitely keep tracks of SS and SP for all CPU levels
>including kernel mode also (ring 0), so that when we are switching form
>user space to kernel space the processor can switch the stacks
>automatically. At stack switching time CPU expects the SS and SP
>elements of TSS to be right, it's just going to copy those values in SS
>and SP registers of CPU, so that now we can push and pop the things on
>the kernel stack.
	In Linxu , the SS and DS normally holds the same value. Mostly I
have seen that,\
 when in kernel mode, DS=SS=0x18 and when in user mode DS=SS=0x28 
(this is what i remember !). 

As Linux does not believe in x86 processor recommended task switching (ie
storing/retrieving all the
necessary register values in a TSS) it uses the process's stack to hold the
required registers. 
But, it cannot get away from the fact that, when a switch happens to kernel
mode,
 the processor expects to find the SS and ESP values for that privilege
level in the current TSS
 (the one which i pointed to be the TS register if i am correct!).

In Linux, we have only one TSS per processor, and when a process is
scheduled most 
probably the kernel sets the  TSS's SS0 (SS corresponding to ring 0) as 0x18
and ESP0 
will be current process's task_struct + 8K (in 2.4). Again, I have not
really gone through
 that piece of code in the kernel, so this is my assumption. Correct me if I
am wrong.

RE: Kernel stack

[Dhiman, Gaurav]

You discussed that kernel do not keep track of SS for process specific
kernel stack as it always starts from fixed offset of task_struct, but
does that mean, linux kernel do not make use of SS element in the TSS of
process. I think the kernel can not by-pass the rules defined by
processor. Processor expects the SS and SP elements to be right at the
time of stack switching, so we need to initialize them to the right
values while forking a process.

I think kernel definitely keep tracks of SS and SP for all CPU levels
including kernel mode also (ring 0), so that when we are switching form
user space to kernel space the processor can switch the stacks
automatically. At stack switching time CPU expects the SS and SP
elements of TSS to be right, it's just going to copy those values in SS
and SP registers of CPU, so that now we can push and pop the things on
the kernel stack.

Yes it definitely can happen (and I think this is the way to do it) that
SS in process's TSS is initialized to the memory address just next to
task_struct (as the kernel stack can grow downwards till this limit)
while the forking of a process and also sets the SP to the fixed offset
from task_struct from where the kernel stack starts growing downwards
(as you mentioned kernel stack starts from there). Now whenever this
process will be scheduled by the scheduler or a process enters the
kernel mode, CPU's SS and SP registers are re-set to the SS and SP
elements in TSS of that process.

At the time of scheduling, scheduler also change the TSS descriptor for
that CPU on which the process is going to be scheduled. It changes this
TSS descriptor in GDT to point to the TSS of the selected process.

Correct me if I am wrong.

Cheers !!
Gaurav


-----Original Message-----
From: Jan Hudec [mailto:bulb@vagabond.light.src] On Behalf Of Jan Hudec
Sent: Tuesday, October 12, 2004 6:42 PM
To: aq
Cc: suthambhara nagaraj; Dhiman, Gaurav; main kernel; kernel
Subject: Re: Kernel stack

On Tue, Oct 12, 2004 at 21:30:54 +0900, aq wrote:
> > > >From what you all discuss, I can say: kernel memory is devided
into 2
> > > part, and the upper part are shared between processes. The below
part
> > > (the kernel stack, or 8K traditionally) is specifict for each
process.
> > >
> > > Is that right?
> > 
> > No, it's not. There is just one kernel memory. In it each process
has
> > it's own task_struct + kernel stack (by default 8K). There is no
special
> > address mapping for these, nor are they allocated from a special
area.
> > 
> > When a context of some process is entered, esp is pointed to the top
of
> > it's stack. That's exactly all it takes to exchange stacks.
> 
> OK, lets say there are 20 processes running in the system. Then the
> kernel must allocate 20 * 8K = 160K just for the stacks of these
> processes. All of these 160K always occupy the kernel (kernel memory
> is never swapped out). When a process actives, ESP would switch to
> point to the corresponding stack (of that process).

This is correct.

> The remainding memory of kernel therefore is equally accessible to all
> the processes.

This is not. There is nothing like "remaining memory". **ALL* kernel
memory is equally accessible to all the processes.

There is noting special about the stacks and task-structs. They are
normal 8K structures somewhere in kernel memory.

> Is that correct ?

------------------------------------------------------------------------
-------
						 Jan 'Bulb' Hudec
<bulb@ucw.cz>

Re: Kernel stack

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Tue, Oct 12, 2004 at 15:30:34 +0100, Jon Masters wrote:
> On Tue, 12 Oct 2004 11:41:04 +0200, Jan Hudec <bulb@ucw.cz> wrote:
> 
> > The base of the stack does not have to be stored either, because it is
> > AT FIXED OFFSET from the task_struct! If you don't believe me, look at
> > definition of the current macro. It says just (%esp & ~8195) (it says it
> > in assembly, because you can't directly access registers from C, and it
> > uses some macros that mean "two pages" instead of 8195).
> 
> The pedant in me wants to point out that 8K is 0-8191 and not 0-8195 :-)

OOPS, a braino ;-).

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Kernel stack

[Jon Masters]

On Tue, 12 Oct 2004 11:41:04 +0200, Jan Hudec <bulb@ucw.cz> wrote:

> The base of the stack does not have to be stored either, because it is
> AT FIXED OFFSET from the task_struct! If you don't believe me, look at
> definition of the current macro. It says just (%esp & ~8195) (it says it
> in assembly, because you can't directly access registers from C, and it
> uses some macros that mean "two pages" instead of 8195).

The pedant in me wants to point out that 8K is 0-8191 and not 0-8195 :-)

Jon.

Re: Kernel stack

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

On Tue, Oct 12, 2004 at 21:30:54 +0900, aq wrote:
> > > >From what you all discuss, I can say: kernel memory is devided into 2
> > > part, and the upper part are shared between processes. The below part
> > > (the kernel stack, or 8K traditionally) is specifict for each process.
> > >
> > > Is that right?
> > 
> > No, it's not. There is just one kernel memory. In it each process has
> > it's own task_struct + kernel stack (by default 8K). There is no special
> > address mapping for these, nor are they allocated from a special area.
> > 
> > When a context of some process is entered, esp is pointed to the top of
> > it's stack. That's exactly all it takes to exchange stacks.
> 
> OK, lets say there are 20 processes running in the system. Then the
> kernel must allocate 20 * 8K = 160K just for the stacks of these
> processes. All of these 160K always occupy the kernel (kernel memory
> is never swapped out). When a process actives, ESP would switch to
> point to the corresponding stack (of that process).

This is correct.

> The remainding memory of kernel therefore is equally accessible to all
> the processes.

This is not. There is nothing like "remaining memory". **ALL* kernel
memory is equally accessible to all the processes.

There is noting special about the stacks and task-structs. They are
normal 8K structures somewhere in kernel memory.

> Is that correct ?

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Kernel stack

[aq]

> > >From what you all discuss, I can say: kernel memory is devided into 2
> > part, and the upper part are shared between processes. The below part
> > (the kernel stack, or 8K traditionally) is specifict for each process.
> >
> > Is that right?
> 
> No, it's not. There is just one kernel memory. In it each process has
> it's own task_struct + kernel stack (by default 8K). There is no special
> address mapping for these, nor are they allocated from a special area.
> 
> When a context of some process is entered, esp is pointed to the top of
> it's stack. That's exactly all it takes to exchange stacks.

OK, lets say there are 20 processes running in the system. Then the
kernel must allocate 20 * 8K = 160K just for the stacks of these
processes. All of these 160K always occupy the kernel (kernel memory
is never swapped out). When a process actives, ESP would switch to
point to the corresponding stack (of that process).

The remainding memory of kernel therefore is equally accessible to all
the processes.

Is that correct ?

Thank you,
AQ

Re: Kernel stack

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

On Tue, Oct 12, 2004 at 19:05:52 +0900, aq wrote:
> > There is no SS entry, because SS does not specify the stack. It is siply
> > a segment in which the stack lives. Any segment, that covers all address
> > space will do! IIRC in kernel SS == DS.
> yes, if I am right, in Linux SS, DS and CS all point to the same base
> address ( = 0 ?). To be exact, SS !=DS, since the segment registers in
> protected mode point to segment selectors (in GDT ?), and we should
> compare the value stored GDT entries, not the value of SS and DS in
> this case.

Of course. Though since DS and SS need the same parameters, they might
actualy point to the same GDT entry. I don't know if they actualy do,
though.

By the way, C compilers usualy set SS and DS with same base. They would
have to do conversion when taking pointers to local variables otherwise.

> > The kernel stack is allocated together with the task_struct. Two pages
> > are allocated and task_struct is placed at the start while the stack is
> > placed at the end and grows down towards the task_struct.
> 2 pages of kernel stack or not is optional. Recently version of kernel
> allow you to choose to use 4K or 8K size for kernel stack.

Yes, it does. Few people touch the "Kernel Hacking" though...

> >From what you all discuss, I can say: kernel memory is devided into 2
> part, and the upper part are shared between processes. The below part
> (the kernel stack, or 8K traditionally) is specifict for each process.
> 
> Is that right?

No, it's not. There is just one kernel memory. In it each process has
it's own task_struct + kernel stack (by default 8K). There is no special
address mapping for these, nor are they allocated from a special area.

When a context of some process is entered, esp is pointed to the top of
it's stack. That's exactly all it takes to exchange stacks.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Kernel stack

[aq]

> There is no SS entry, because SS does not specify the stack. It is siply
> a segment in which the stack lives. Any segment, that covers all address
> space will do! IIRC in kernel SS == DS.
yes, if I am right, in Linux SS, DS and CS all point to the same base
address ( = 0 ?). To be exact, SS !=DS, since the segment registers in
protected mode point to segment selectors (in GDT ?), and we should
compare the value stored GDT entries, not the value of SS and DS in
this case.

> The kernel stack is allocated together with the task_struct. Two pages
> are allocated and task_struct is placed at the start while the stack is
> placed at the end and grows down towards the task_struct.
2 pages of kernel stack or not is optional. Recently version of kernel
allow you to choose to use 4K or 8K size for kernel stack.

>From what you all discuss, I can say: kernel memory is devided into 2
part, and the upper part are shared between processes. The below part
(the kernel stack, or 8K traditionally) is specifict for each process.

Is that right?

Regards,
AQ

Re: Kernel stack

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

On Tue, Oct 12, 2004 at 12:21:37 +0530, suthambhara nagaraj wrote:
> 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 .

Yes. Thus each process has it's own TSS. It is just stored differently
when the process is not scheduled.

It comes out of that, that the stack is NOT shared among different
processes, because it is replaced whenever a different process is
scheduled on a CPU.

> 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.

There is no SS entry, because SS does not specify the stack. It is siply
a segment in which the stack lives. Any segment, that covers all address
space will do! IIRC in kernel SS == DS.

The base of the stack does not have to be stored either, because it is
AT FIXED OFFSET from the task_struct! If you don't believe me, look at
definition of the current macro. It says just (%esp & ~8195) (it says it
in assembly, because you can't directly access registers from C, and it
uses some macros that mean "two pages" instead of 8195).

The kernel stack is allocated together with the task_struct. Two pages
are allocated and task_struct is placed at the start while the stack is
placed at the end and grows down towards the task_struct.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Kernel stack

[Thekkedath, Gopakumar]

-----Original Message-----
From: suthambhara nagaraj [mailto:suthambhara@gmail.com]
Sent: Tuesday, October 12, 2004 12:22 PM
To: Dhiman, Gaurav
Cc: main kernel; kernel
Subject: Re: Kernel stack


>in another structure( struct thread_struct ).A kernel stack of size 8k
>(By default)
>is actully shared by processes running on a processor. 
	Each process has its own kernel mode stack, in fact it starts from
the process's task_struct start address + 8K (atleast in 2.4). (This also
helps in the implementation of 'current')

>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


	Again, in linux implementaton, for each process, SS is the same ,
but ESP differs and hence the stack


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/
> 
>

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/

Re: Kernel stack

[suthambhara nagaraj]

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/
> 
>

Re: Kernel stack....

[Richard J Moore]

If you have an interrupt stack, and that's not strictly necessary in OS
design, then you either need one per processor or to handle interrupts on
only one processor. If you use the task time kernel stack, which under IA32
you will do as soon as the CPU processes the interrupt gate for that IRQ,
then the interrupt stack frame wil appear on the task time stack. Things in
theory can continue this was. Eventually the stack will unwind with the
interrupt frame being finally removed with an IRET. No it is possible to
switch to a separate stack but that has to be engineered by the system
interrupt handler. I don't recall whether Linux does this. If it does
you'll see it happening in the /arch code for interrupt handling.

Richard Moore -  RAS Project Lead - Linux Technology Centre (ATS-PIC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK


                                                                                                                                   
                    Emmanuel Varagnat                                                                                              
                    <Emmanuel_Varagnat-AEV010@emai       To:     Richard J Moore/UK/IBM@IBMGB                                      
                    l.mot.com>                           cc:                                                                       
                                                         Subject:     Re: Kernel stack....                                         
                    11/09/2001 16:26                                                                                               
                    Please respond to Emmanuel                                                                                     
                    Varagnat-AEV010                                                                                                
                                                                                                                                   
                                                                                                                                   




Richard J Moore wrote:
>
> Emmanuel Varagnat wrote:
>
> >Yes but there is one stack per processor ?
>
> One per process.

Yes I know, but inside the kernel when an IRQ is handled
the kernel use its own stack. But if there is many processors
many IRQ handler are supposed "turn". And if they share the
same stack, data are melted.

Thanks for your answer.

-Manu

Re: Kernel stack....

[Richard B. Johnson]

On Mon, 10 Sep 2001, Raghava Raju wrote:

> 
> 
> Hi,
> 
>       1) I want to know what exactly is the structure
> of kernel stack. Is it some thing like bss,data,text?
> 
>       2) I want to access kernel stack(in kernel
> mode). So I am using  kernel stack pointer provided in
> thread_struct. So how to access different areas(.i.e 
> data,text)  in kernel stack.
> 
> 
>        Any pointers will be helpful.
> 
>    Please mail me as I did't subscribe.
>    vraghava_raju@yahoo.com
> 
>      Thank you.
>      Raj. 

I am assuming that you want to know how parameters loaded on the
stack are passed to called procedures, i.e., the offset. I assume
that you know that the kernel stack is just like a user stack and
you don't actually manipulate it directly.

Given:
	procedure(one, two, three);
where one, two, and three are values of any size up to the length
of a register..

The called procedure gets the values as:

	0x04(%esp) = one
	0x08(%esp) = two
	0x0c(%esp) = three

If, and only if, no registers are saved on the called procedure's
stack. If some register(s) have been saved, the parameters are
offset by the length of the register(s)...

proc:	pushl	%ebx
	pushl	%ecx
	pushl	%edx
	pushl	%edi			# 4 * 4 = 0ffset 16
	movl	0x14(%esp), %ebx	# One
	movl	0x18(%esp), %ecx	# Two
	movl	0x1c(%esp), %edx	# Three


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Kernel stack....

[Emmanuel Varagnat]

Erik Mouw wrote:
> 
> I think you got a wrong understanding of the stack. The stack has no
> separate bss, data, and text sections, it's just a stack of function
> arguments, local variables, and return addresses.
> 
> Accessing the stack works automatically: call a function, and the
> function paramaters and the return address are pushed on the stack.

Yes but there is one stack per processor ?
And what about its maximum size ? Is it dynamical ?

-Manu

Re: Kernel stack....

[Erik Mouw]

On Mon, Sep 10, 2001 at 02:47:41PM -0700, Raghava Raju wrote:
>       1) I want to know what exactly is the structure
> of kernel stack. Is it some thing like bss,data,text?
> 
>       2) I want to access kernel stack(in kernel
> mode). So I am using  kernel stack pointer provided in
> thread_struct. So how to access different areas(.i.e 
> data,text)  in kernel stack.

I think you got a wrong understanding of the stack. The stack has no
separate bss, data, and text sections, it's just a stack of function
arguments, local variables, and return addresses.

Accessing the stack works automatically: call a function, and the
function paramaters and the return address are pushed on the stack.
Unless you have a *very* good reason, there is no need to manipulate
the stack directly in kernel mode.


Erik

PS: Please don't cross post between the kernelniewbes and linux-kernel
  lists, use only one of them next time (kernelnewbies is good for this
  kind of questions).

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Kernel stack....

[Raghava Raju]

Hi,

      1) I want to know what exactly is the structure
of kernel stack. Is it some thing like bss,data,text?

      2) I want to access kernel stack(in kernel
mode). So I am using  kernel stack pointer provided in
thread_struct. So how to access different areas(.i.e 
data,text)  in kernel stack.


       Any pointers will be helpful.

   Please mail me as I did't subscribe.
   vraghava_raju@yahoo.com

     Thank you.
     Raj. 

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

Kernel stack...

[Raghava Raju]

 Hi 

   Kindly provide me with some basic insights
  into kernel.

 1) I want to know exact structure of kernel stack
  and process stack in memory. It would be helpful
  if description includes approximate memory addresses
  of kernel stack,process stack, and different regions
  in kernel stack and process stack. What happens 
  if there are multiple processes.

 2) What about "current" data structure. Where is it
  located  on memory. If I am not wrong it will be 
  just below the process stack.

 3)Which variable to use to access (I am in kernel
   code) kernel stack. In "task_struct" 
   kernel_stack_page is not defined. Mine is 
   "linux 2.4.2 mvista".

  I am not subscribed to this list, kindly send
  me the reply to vraghava_raju@yahoo.com .

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/