Hi, Thanks for the response. But it appears your example illustrates why its bad to sleep while you have a lock. Which I understand, what I wanted to know is why in interrupt context under no circumstances are you allowed to sleep?
Btw I have no intention of doing this, I'm just curious. After thinking about it further I'm starting to think its a "design" decision as opposed to a side effect of the kernel implementation. If you could answer: "How can the system timer ( obviously in interrupt context ) call schedule when it is impossible to sleep/schedule in interrupt context?" That would help me greatly. Thanks again iain On Fri, Oct 5, 2012 at 10:32 AM, Borislav Petkov <b...@alien8.de> wrote: > On Fri, Oct 05, 2012 at 09:51:55AM +0100, Iain Fraser wrote: >> Hello, >> >> I understand the interrupts and softirq's run in interrupt context ( >> as opposed to process context ). But what I >> don't understand is why you cannot sleep in interrupt context? >> >> What I have read it states that it doesn't have a process to schedule >> out. But interrupts use the interrupted processes >> kernel stack just like a syscall. So surely it is possible to sleep >> using that stack. Understandably It would be unfair on the process >> that blocked through no fault of its own. >> >> Also if you are not allowed to sleep / schedule during interrupt >> context. Then how does the system timer pre-empt processes by >> calling schedule? >> >> I understand there are many reasons why you shouldn't: irq lines being >> disabled, quick completion, etc. But I don't understand >> why you cannot. > > Let's imagine for a second we could sleep in IRQ context and we had some > dummy process entity we can schedule out from. > > So, we schedule out and run another process which enters the kernel and > grabs a lock L. > > At that exact moment, another IRQ on the same line is raised, we execute > the same IRQ handler which purely coincidentally starts busy-waiting on > the same lock L. > > How long do you think we'll be busy waiting in IRQ context on that lock? > > :-) > > HTH. > > -- > Regards/Gruss, > Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
