From: Neil Horman <nhorman@redhat.com>
To: suthambhara nagaraj <suthambhara@gmail.com>
Cc: main kernel <linux-kernel@vger.kernel.org>
Subject: Re: kernel stack
Date: Tue, 12 Oct 2004 07:09:09 -0400 [thread overview]
Message-ID: <416BBB55.6020509@redhat.com> (raw)
In-Reply-To: <46561a79041011231549ea310a@mail.gmail.com>
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
***************************************************/
next prev parent reply other threads:[~2004-10-12 11:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-12 6:15 kernel stack suthambhara nagaraj
2004-10-12 11:09 ` Neil Horman [this message]
2004-10-13 3:29 ` suthambhara nagaraj
2004-10-14 3:15 ` suthambhara nagaraj
-- strict thread matches above, loose matches on Subject: below --
2004-10-13 5:03 Kernel stack Thekkedath, Gopakumar
2004-10-13 4:35 Dhiman, Gaurav
2004-10-14 19:31 ` Denis Vlasenko
2004-10-12 7:51 Thekkedath, Gopakumar
[not found] <577528CFDFEFA643B3324B88812B57FE3055B9@inhyms21.ca.com>
2004-10-12 6:51 ` suthambhara nagaraj
2004-10-12 9:41 ` 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
2001-09-11 15:53 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=416BBB55.6020509@redhat.com \
--to=nhorman@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=suthambhara@gmail.com \
/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