lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 5 Oct 2012 12:34:04 +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 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@...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

Powered by Openwall GNU/*/Linux Powered by OpenVZ