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: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ