Re: interrupt context

[Borislav Petkov]

On Fri, Oct 05, 2012 at 11:20:20AM +0100, Iain Fraser wrote:
> 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.

There are more examples where sleeping in IRQ context is simply
problematic. So prohibiting sleeping in such contexts turns out to be
the simplest solution concerning code complexity, design, handling, etc.

Btw, you can trigger some yourself by adding sleeping functions in an
IRQ handler used on your system, disable the "sleeping-while-atomic"
warnings and try to run it to see what happens.

> 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?"

I think the best way to learn these things is to stare at the code until
you've understood exactly what it does when it does it, so I'll let you
answer that.

And you want to learn because you wouldn't be asking those questions in
the first place. :-)

HTH.

-- 
Regards/Gruss,
    Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/