On Thu, Apr 16, 2009 at 6:03 AM, pradeep singh <pradeep.rautela@xxxxxxxxx> wrote: > On Wed, Apr 15, 2009 at 6:51 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >> Hi Pradeep, >> >> On Wed, Apr 15, 2009 at 6:59 AM, pradeep singh >> <pradeep.rautela@xxxxxxxxx> wrote: >>> On Wed, Apr 15, 2009 at 12:20 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >>> [...] >>>>> What I know is that there are only two types of contextes: process, and >>>>> interrupt. Hardware interrupt handler and deferrable functions(including >>>>> softirq and tasklete) run in interrupt context. >>>>> >>>> >>>> well....hardware interrupt context is when the hardware IRQ flag is >>>> still set, which will be turned off (via hardware - not software) when >>>> u do a iret. >>>> >>>> software interrupt context is a kernel processing loop trying to clear >>>> up all the remaining activities outstanding from hardware interrupt >>>> context. >>>> >>>> and process context is when the kernel switch over to execute with >>>> full pagetable addrespace ownership (see below). >>>> >>>> In Intel manual there is something called "software >>>> interrupts".....nothing to do with anything mentioned here. >>>> >>>>>> >>>>>> read this for further details (from LDDv3): >>>>>> >>>>>> http://lwn.net/images/pdf/LDD3/ch07.pdf >>>>>> >>>>>> within it explained what is a kernel thread. So basically while >>>>>> running process A in kernel mode, it can be intercepted by any kernel >>>>>> threads, and these kernel threads therefore "DOES NOT HAVE PROCESS >>>>>> CONTEXT", as they are not related to the currently running process A, >>>>> If these threads does not have process context, then what context are they in? >>>>> hardware interrupt context? software interrupt context? Or you'll create another >>>>> new context named "thread context"? >>>>> >>>> >>>> Firstly, it is related to Intel hardware MMU/pagetable/CR3 mechanism. >>>> In Linux kernel design, there is no change in the pagetables when >>>> transition from kernel to user space (and vice versa) are made - >>>> because of performance cost (called lazy-TLB). It is switch only >>>> when there is a process switch - by changing the CR3. >>>> >>>> "No process context" actually means that the taskstruct's >>>> mm_struct->mm is NULL. >>> >>> Hi Peter, I wonder saying no process context will be appropriate here? >>> They do have a process context because scheduler does not differentiate between >>> kernel threads and other processes AFAIK. right? >>> >> >> Yes, u are right, kernel threads and processes are all schedulable. >> >> Let me quote another source for explanation: >> >> http://www.linuxquestions.org/linux/articles/Technical/Linux_Kernel_Thread >> >> "KERNEL THREADS >> >> Kernels can attain parallelism by spawning some operations in the >> background. The kernel achieves this by delegating these operations to >> the kernel threads. A kernel thread is a process that exists only in >> kernel space and does not have access to user address space i.e. mm >> pointer is NULL. Being an integral part of a kernel and running in a > > I doubt if this is true Peter. Kernel threads do have access to user space they > just do not have an associated user space context . > Why I so say is because of the following code snippet kernel_thread() - > regs.ds = __USER_DS > regs.es = __USER_ES > I really don't know why....but my guess is that it is done for legacy purpose, as well consistency (signal handler all set it to __USER_DS). But important thing is, after it is set, it is not use at all. >From an email 10 years back: http://lkml.indiana.edu/hypermail/linux/kernel/9808.3/0436.html it is already mentioned as unused....not sure about now. But in real mode this is quite important, not in protected mode. > So, if you are right then why set ds and es segments to __USER_DS in > segment descriptors? > > Or did I misinterpret it? > > Thanks, > --Pradeep > >> kernel address space, they have an access to kernel data structures. A >> Kernel thread does not have a privilege over other processes and hence >> they are also as schedulable and pre-emptable as any other process." >> >> read the article......very readable. thanks. >> >> >> -- >> Regards, >> Peter Teoh >> > > > > -- > Pradeep > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
