[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121005093232.GA7333@liondog.tnic>
Date: Fri, 5 Oct 2012 11:32:32 +0200
From: Borislav Petkov <bp@...en8.de>
To: Iain Fraser <iainkfraser@...il.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: interrupt context
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists