Contents of CR3 register when a kernel thread is executed

Contents of CR3 register when a kernel thread is executed

[limp]

Hi all,

I am trying to understand in what extend the PGD (page global directory)
value stored in the CR3 register indicate the running process/thread by the
Linux scheduler.

I know that each process has its own PGD value but what I am confused about
is the value of CR3 register when kernel threads are scheduled.

AFAIK, a "kernel thread" can 'borrow' the page-directory that belongs to
another process (i.e. its address space). Does this apply *only* to threads
of the same process (i.e. all the threads of process A are using the PGD
entry of process A) or could also apply to threads not relevant to process
A?

That is, if a thread is executed and the value of CR3 at the time is
0x1E107000, does this *necessary* mean that a thread of the process with PGD
0xDE107000 is executed *or* a thread not relevant with that process could
have 'borrowed' its PGD entry?

Any help will be greatly appreciated.

John K.

Contents of CR3 register when a kernel thread is executed

[Mulyadi Santosa]

On 18/04/2011, limp <johnkyr83@hotmail.com> wrote:
> Hi all,
>
> I am trying to understand in what extend the PGD (page global directory)
> value stored in the CR3 register indicate the running process/thread by the
> Linux scheduler.
>
> I know that each process has its own PGD value but what I am confused about
> is the value of CR3 register when kernel threads are scheduled.

kernel thread(s) simply borrow latest scheduled process's PGD ( that
means, the entire address space)....this is done to save unneccessary
TLB flush since kernel thread operates in kernel space and that's the
same to all processes

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Contents of CR3 register when a kernel thread is executed

[Peter Teoh]

On Mon, Apr 18, 2011 at 9:17 PM, limp <johnkyr83@hotmail.com> wrote:

> Hi all,
>
> I am trying to understand in what extend the PGD (page global directory)
> value stored in the CR3 register indicate the running process/thread by the
> Linux scheduler.
>



>
> I know that each process has its own PGD value but what I am confused about
> is the value of CR3 register when kernel threads are scheduled.
>
>
yes, each process has its own CR3 value -> u can easily see this when u do a
printk() of it....and it is always equal to the process (which is "insmod"
usually) that started the kernel module.   i experimented it here:

http://www.issociate.de/board/post/492650/Does_cr3_register_change_when_a_new_process_is_scheduled_?.html


> AFAIK, a "kernel thread" can 'borrow' the page-directory that belongs to
> another process (i.e. its address space). Does this apply *only* to threads
>

yes, "borrow" in the sense that:   kernel thread DOES NOT have any process
context, and so it can be executed in any process context, and which ever
process context it is executing, when u print the CR3 value, it will belong
to that process which the kernel thread is currently executing under.

read this:

http://www.scs.ch/~frey/linux/kernelthreads.html


> of the same process (i.e. all the threads of process A are using the PGD
> entry of process A) or could also apply to threads not relevant to process
> A?
>
> That is, if a thread is executed and the value of CR3 at the time is
> 0x1E107000, does this *necessary* mean that a thread of the process with
> PGD
> 0xDE107000 is executed *or* a thread not relevant with that process could
> have 'borrowed' its PGD entry?
>
> Any help will be greatly appreciated.
>
> John K.
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110419/ad7e8808/attachment.html 

Contents of CR3 register when a kernel thread is executed

[limp]

Thank you all for your replies,

> yes, "borrow" in the sense that: ? kernel thread DOES NOT have any process
> context, and so it can be executed in any process context, and which ever
> process context it is executing, when u print the CR3 value, it will
belong
> to that process which the kernel thread is currently executing under.

I've read on LKD by Robert Love book the following:
"Because kernel threads do not have any pages in user-space, they do not
really
deserve their own memory descriptor and page tables. Despite this, kernel
threads
need some of the data, such as the page tables, even to access kernel
memory.
To provide kernel threads the needed data, kernel threads use the memory
descriptor
of whatever task ran previously"

I can't really tell which are the data which are needed by kernel threads
that the
book is talking about..By combining the above with the following (from the
same book): 

"The kernel thread can then use the previous process's page tables as
needed. Because
kernel threads do not access user-space memory, they make use of only the
information
in the address space pertaining to kernel memory, which is the same for all
processes."

I conclude the following:
A kernel thread uses only the address space of the previously scheduled user
process
pertaining to kernel memory for accessing kernel memory. Also, a kernel
thread is using
the virtual memory mechanism of user process to access kernel memory. That
is, it runs
on user-space but accesses *only* kernel memory, right? - i.e. it is
basically a user
process that access only Kernel memory - Why kernel threads cannot directly
access
kernel memory and use a mechanism used in user-space for accessing it?

Sorry for the many questions, any help will be greatly appreciated guys. 

P.S. Please correct me if I interpreted something wrong.

Regards,

John K.

Contents of CR3 register when a kernel thread is executed

[Dave Hylands]

Hi John,

2011/4/20 limp <johnkyr83@hotmail.com>:
> Thank you all for your replies,
>
>> yes, "borrow" in the sense that: ? kernel thread DOES NOT have any process
>> context, and so it can be executed in any process context, and which ever
>> process context it is executing, when u print the CR3 value, it will
> belong
>> to that process which the kernel thread is currently executing under.
>
> I've read on LKD by Robert Love book the following:
> "Because kernel threads do not have any pages in user-space, they do not
> really
> deserve their own memory descriptor and page tables. Despite this, kernel
> threads
> need some of the data, such as the page tables, even to access kernel
> memory.
> To provide kernel threads the needed data, kernel threads use the memory
> descriptor
> of whatever task ran previously"
>
> I can't really tell which are the data which are needed by kernel threads
> that the
> book is talking about..By combining the above with the following (from the
> same book):

The data being referred to is the memory which contains the page
tables which provide the mapping from virtual to physical addresses.

The page tables are actually allocated out of system memory. The MMU
only uses them, it doesn't have any memory of its own (except for
things like TLB caches).

> "The kernel thread can then use the previous process's page tables as
> needed. Because
> kernel threads do not access user-space memory, they make use of only the
> information
> in the address space pertaining to kernel memory, which is the same for all
> processes."
>
> I conclude the following:
> A kernel thread uses only the address space of the previously scheduled user
> process
> pertaining to kernel memory for accessing kernel memory. Also, a kernel
> thread is using
> the virtual memory mechanism of user process to access kernel memory. That
> is, it runs
> on user-space but accesses *only* kernel memory, right? - i.e. it is
> basically a user
> process that access only Kernel memory - Why kernel threads cannot directly
> access
> kernel memory and use a mechanism used in user-space for accessing it?

Well - yeah that's sort of right. Except that kernel threads aren't
really in any "process", unless perhaps you consider the entire kernel
to be one big process.

Every user process has the kernel space mapped into it, but it's not
accessible unless you're in "supervisor" mode. When you transition
from user space to kernel space, you switch to supervisor mode and you
can now access kernel memory.

For example, 0xc0000000 - 0xffffffff is typically your kernel space,
and 0x00000000 - 0xbfffffff is user space (there are lots of
variations, this is just an example).

Since the kernel threads don't access the memory below 0xc0000000,
every kernel thread sees the same mapping.

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

Contents of CR3 register when a kernel thread is executed

[Peter Teoh]

2011/4/21 limp <johnkyr83@hotmail.com>

> Thank you all for your replies,
>
> > yes, "borrow" in the sense that:   kernel thread DOES NOT have any
> process
> > context, and so it can be executed in any process context, and which ever
> > process context it is executing, when u print the CR3 value, it will
> belong
> > to that process which the kernel thread is currently executing under.
>
> I've read on LKD by Robert Love book the following:
> "Because kernel threads do not have any pages in user-space, they do not
> really
> deserve their own memory descriptor and page tables. Despite this, kernel
> threads
> need some of the data, such as the page tables, even to access kernel
> memory.
> To provide kernel threads the needed data, kernel threads use the memory
> descriptor
> of whatever task ran previously"
>
> I can't really tell which are the data which are needed by kernel threads
> that the
> book is talking about..By combining the above with the following (from the
> same book):
>
> "The kernel thread can then use the previous process's page tables as
> needed. Because
> kernel threads do not access user-space memory, they make use of only the
> information
> in the address space pertaining to kernel memory, which is the same for all
> processes."
>
> I conclude the following:
> A kernel thread uses only the address space of the previously scheduled
> user
> process
> pertaining to kernel memory for accessing kernel memory. Also, a kernel
> thread is using
> the virtual memory mechanism of user process to access kernel memory. That
> is, it runs
> on user-space but accesses *only* kernel memory, right? - i.e. it is
> basically a user
> process that access only Kernel memory - Why kernel threads cannot directly
> access
> kernel memory and use a mechanism used in user-space for accessing it?
>
> because all virtual memory access need a page table, so since the kernel
thread DOES not have a page table (as it does not have a process context),
as pagetable are stored per-process (why?  because so that through the MMU
translation mechanism, each process thought that it has 4GB of memory
available), so it has no choice but to use the process's pagetable.

but because of the kernel area is shared, and therefore, the pagetable for
the kernel part is also shared by all process's pagetable.   and the base of
this table is pointed to by hardware - CR3, but only when protected mode is
setup.

note too there is a such a thing as linear and non-linear mapping:   getting
physical address from virtual address is easy....just reference the page
table.   but getting the reverse is easy - if it is linearly mapped - which
is true for the kernel memory (GFP_KERNEL) but not true for the highmem part
(GFP_HIGHMEM).   Looking into vmalloc.c for non-linear memory allocation.


> Sorry for the many questions, any help will be greatly appreciated guys.
>
> P.S. Please correct me if I interpreted something wrong.
>
> Regards,
>
> John K.
>
>


-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110421/8936bf88/attachment.html