task switching and current pointer implemenation question

subin gangadharan subingangadharan at gmail.com
Sat Dec 10 14:15:34 EST 2011


Hi Dave,

Thanks a lot for your crystal clear explanation of my question.
Now I understood, actually I was thinking there will be only one stack
in kernel space which will be shared
by all apps.

Thanks again.


On Sat, Dec 10, 2011 at 1:00 PM, Dave Hylands <dhylands at gmail.com> wrote:
> Hi Subin,
>
> On Sat, Dec 10, 2011 at 7:35 AM, subin gangadharan
> <subingangadharan at gmail.com> wrote:
>>
>> Hi Guys,
>>
>> I have a question related to task switching.Basically when user space
>> application switches to kernel (through sys calls),
>> which stack will be used for the user app.Mainly I want to know how
>> the current pointer implementation works.
>> I saw that in arm they are masking the sp with ~(THREAD_SIZE -1) and
>> getting the current thread info and from there its
>> taking the task pointer.
>>
>> So here I am a little confused about the stack pointer since when it
>> switches the kernel it will be supervisory mode,so which
>> sp it's referencing.I know it will be a supervisory stack,but how this
>> stack will be related with the user app.
>
>
> Every thread gets a kernel stack (typically of around 8K, although this can
> vary by config options and architecture). This stack is created when the
> thread is created. Whenever the code transitions from kernel space into user
> space, the kernel sp is saved and the user sp is restored. When calling from
> user-space into kernel space, the user-sp is saved and the kernel-sp is
> restored.
>
> Each thread has some thread-info which is stored on the low end of the
> stack. Since the stacks are 8K is size and 8K aligned (or some other power
> of 2 in size and the same power of 2 aligned), you can do a simple masking
> operation with the sp to retrieve the thread-info.
>
> --
> Dave Hylands
> Shuswap, BC, Canada
> http://www.davehylands.com



-- 
With Regards
Subin Gangadharan

I am not afraid and I am also not afraid of being afraid.



More information about the Kernelnewbies mailing list