kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: dhylands@gmail.com (Dave Hylands)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Identifying whether a user-process or kernel-thread execution takes place by looking at CPU registers
Date: Sat, 14 May 2011 12:12:21 -0700	[thread overview]
Message-ID: <BANLkTimAmswYvKrz7bO-wy_UEqs89rdozg@mail.gmail.com> (raw)
In-Reply-To: <SNT111-DS476A9195D7B5BC0D82251A78B0@phx.gbl>

Hi John,

On Sat, May 14, 2011 at 10:55 AM, limp <johnkyr83@hotmail.com> wrote:
> Thank you all for your replies.
>
>> If you want details about how to determine the task_struct from SP, I
>> can get into that, although it's subject to change. Using "current" it
>> the normal technique.
>
> Yes, I want to determine the "task_struct" from the SP. According to what I
> read, on x86 "current" is calculated by masking out the 13 least significant
> bits of the stack pointer to obtain the "thread_info" structure and
> consequently
> the "task_struct". Is that what you had in mind?

Well, what you get from the SP is something called thread_info (I'm
familiar with ARM)
http://lxr.linux.no/linux+v2.6.38/arch/arm/include/asm/thread_info.h#L50

The function current_thread_info gets the pointer to the thread_info
struct by looking at the stack pointer:
<http://lxr.linux.no/linux+v2.6.38/arch/arm/include/asm/thread_info.h#L94>

The thread_info struct contains a pointer to the task_struct.

So when the stack is allocated, it comes from an 8K chunk of memory (I
think it may be 4K on x86) which is aligned on an 8K boundary, which
is why the masking works. The stack starts at the high end of this and
grow down. The thread_info is stored at the low end, so when you
overflow your stack you corrupt your own thread_info.

It looks like all of the architectures use a similar design.

The thread_info is allocated here:
http://lxr.linux.no/linux+v2.6.38/kernel/fork.c#L118

which is called from here:
http://lxr.linux.no/linux+v2.6.38/kernel/fork.c#L260

> Another question is if the "task_struct" is allocated in contiguous memory
> space as I don't see a "packed" attribute in the structure definition.

Those are mutually independant concepts.

All allocated memory in the kernel is virtually contiguous. Packed
data is when the packing between members in a structure is removed.
<http://en.wikipedia.org/wiki/Data_structure_alignment>

> If yes, do you know of an easy way of finding the offset of the "mm" field
> of the structure so that I can obtain its value? I guess a way is by finding
> it manually from the structure definition but it seems quite complex.

In C there is an offsetof macro:
<http://linux.die.net/man/3/offsetof>
<http://www.netrino.com/Embedded-Systems/How-To/C-Offsetof-Macro>

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com

      reply	other threads:[~2011-05-14 19:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-12 10:55 Identifying whether a user-process or kernel-thread execution takes place by looking at CPU registers limp
2011-05-12 11:53 ` Mulyadi Santosa
2011-05-13  1:55   ` Dave Hylands
2011-05-14 17:55     ` limp
2011-05-14 19:12       ` Dave Hylands [this message]

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=BANLkTimAmswYvKrz7bO-wy_UEqs89rdozg@mail.gmail.com \
    --to=dhylands@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.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;
as well as URLs for NNTP newsgroup(s).