On Wed, Jul 4, 2012 at 10:36 AM, anish singh <anish198519851985@xxxxxxxxx> wrote: > On Wed, Jul 4, 2012 at 1:51 PM, Javier Martinez Canillas > <martinez.javier@xxxxxxxxx> wrote: >> On Tue, Jul 3, 2012 at 4:24 PM, Parmenides <mobile.parmenides@xxxxxxxxx> wrote: >>> Hi, >>> >>> It is said that kernel can not be preempted in interrupt context >>> and when it is in a critical section protected by a spin lock. >>> >>> 1. For the spinlock case, it is easy to get if preemption is allowed >>> in critical section, the purpose of protection provided by spinlock >>> can not be achieved readily. >>> >> >> A process cannot be preempted nor sleep while holding a spinlock due >> spinlocks behavior. If a process grabs a spinlock and goes to sleep >> before releasing it. A second process (or an interrupt handler) that >> to grab the spinlock will busy wait. On an uniprocessor machine the >> second process will lock the CPU not allowing the first process to >> wake up and release the spinlock so the second process can continue, >> it is basically a deadlock. >> >> This happens since grabbing an spinlocks also disables interrupts and >> this is required to synchronize threads with interrupt handlers. >> >>> 2. For the interrupt context case, I think when processing interrupt, >>> kernel can be preempted in principle. But, this really increases the >>> interrupt processing time which further cause longer response time and >>> data missing in device. Except that, is there any other reasons? >>> >> >> The principal reason is quite simple, processes have an associated >> task_struct and get executed when the scheduler chose to run it but >> interrupt handlers are executed due an event (an interrupt happened on >> the registered IRQ line). >> >> So if you preempt an interrupt handler and schedule a process instead, >> how could you execute the interrupt handler again? they don't have an >> associated task_struct since they are not user-space process > In case of threaded handlers also? Threaded irqs of course are different since a kernel thread is created for them. The question he made (and though my answer) was for "interrupt context". Threaded irqs are not run on interrupt contexts but on process context (i.e: in_irq() returns false). >> >>> 3. Kernel is responsible for prohibiiting passive process switches, >>> namely preemption, in the above cases. But, It seems that it does not >>> take care of active process swtiches, namely yield. For example, some >>> code in a critical section protected by a spinlock can invoke >>> schedule() to switch process passively. Is this the case? >>> >> >> Right, the kernel just avoid process switching by disabling preemption >> but you could still call schedule() or do a function call that sleeps >> like allocating big chunks of memory with GFP_KERNEL flag instead of >> GFP_ATOMIC, this is indeed a bug in the same way that is a bug >> dereferencing a NULL pointer. >> >> On the kernel hacking section of the Kbuild configuration you can find >> many kconfig options to enable different debug facilities that helps >> you detect these scenarios and avoid deadlock. >> >> >> Hope it helps, >> Javier >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies@xxxxxxxxxxxxxxxxx >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
