On Wed, Apr 15, 2009 at 02:50:11PM +0800, Peter Teoh wrote:
> apologized if i get my terminologies wrong, or explanation
> unclear......tried my best.....
>
> 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.
So, essentially, they are the same thing. They are all in the interrupt
context. They don't return any value. They can't sleep or reschedule.
They can't be blocked in their execution.
My understanding for software IRQ is that it is triggled by software,
not peripheal hardware event. That is programmer can triggle it in
the kernel whenever you want. Then it is executed just like the hardware
IRQ.
>
> 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.
>
Yes, the software interrupt in Intel manual means exception and trap.
eg: devided by zero, page fault exception. It has nothing to do with
the question we're discussing.
> 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. This means that the pagetable CR3 are not
> changed from its previous value. Therefore, whatever u read/write
> to, u are reading/writing to the previous owner of the address space,
> which is why when u do things like copy_to_user() from kernel threads,
> u are copying to any arbitrary process that happened to be running
> BEFORE the kernel thread is switched.
When you fork a kernel process/thread, is the taskstruct's mm_struct->mm
NULL? Without memory page, what can it do?
I think what you're talking about here is that a process execution switches
from user space to kernel space. There's no kernel thread/process even
the process executes in kernel space. It is still in the original process
context.
>
> For eg,
>
> /*
> * Access another process' address space.
> * Source/target buffer must be kernel space,
> * Do not walk the page table directly, use get_user_pages
> */
> int access_process_vm(struct task_struct *tsk, unsigned long addr,
> void *buf, int len, int write)
> {
> struct mm_struct *mm;
> struct vm_area_struct *vma;
> void *old_buf = buf;
>
> mm = get_task_mm(tsk);
> if (!mm)
> return 0;
>
> The above (!mm) check actually means that the API access_process_vm()
> MUST NOT be executed from a kernel thread env, which does not have any
> process context.
>
> >> and therefore, must observe rules (described in ch07.pdf) like I/O,
> >> sleeping etc. etc.
> >>
> >
>
> For eg, if u do "insmod xxx", your kernel module is running in the
> process context of the "insmod" process.
>
> read this:
>
> http://lwn.net/Articles/147782/
>
> in PREEMPT_RT, there is even a 4th type of context introduced!!!
>
> u are right that there is two context - for eg (executing workqueue in
> process context):
>
> int execute_in_process_context(work_func_t fn, struct execute_work *ew)
> {
> if (!in_interrupt()) {
> fn(&ew->work);
> return 0;
> }
>
> INIT_WORK(&ew->work, fn);
> schedule_work(&ew->work);
>
> return 1;
> }
>
> where it distinguish between process context vs no process context
> just via interrupt process mode. why is in_softirq() not filtered
> off?
>
There exist in_softirq() because sometimes kernel need to distinguish
what kind of handler it is executing: software IRQ handler or hardware
IRQ handler. For example, you can't execute another software IRQ when
you are executing a software IRQ(in software IRQ context).
The meaning of "context" here is not the one when we talk about process
context vs. interrupt context.
> /*
> * Are we doing bottom half or hardware interrupt processing?
> * Are we in a softirq context? Interrupt context?
> */
> #define in_irq() (hardirq_count())
> #define in_softirq() (softirq_count())
> #define in_interrupt() (irq_count())
>
> continue to puzzle it out.............
>
> --
> 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
