linux-kernel - Re: interrupt context

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: <CA+bLfK7+xpbbJp+1sJBOtjoT2auGpbKsVKoDMgRk95o-Fwm9RQ@mail.gmail.com>
Date:	Fri, 5 Oct 2012 11:20:20 +0100
From:	Iain Fraser <iainkfraser@...il.com>
To:	Borislav Petkov <bp@...en8.de>,
	Iain Fraser <iainkfraser@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: interrupt context

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 <bp@...en8.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 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/