linux-kernel - Re: [PATCH] Use delayed disable mode of ioapic edge triggered interrupts

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] [day] [month] [year] [list]

Message-ID: <m1psbo4pgb.fsf@ebiederm.dsl.xmission.com>
Date:	Wed, 15 Nov 2006 09:58:12 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Ingo Molnar <mingo@...hat.com>, Komuro <komurojun-mbn@...ty.com>,
	tglx@...utronix.de, Adrian Bunk <bunk@...sta.de>,
	Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Use delayed disable mode of ioapic edge triggered interrupts

Linus Torvalds <torvalds@...l.org> writes:

> On Tue, 14 Nov 2006, Eric W. Biederman wrote:
>
>> The truth is in practice I don't think it matters because I don't
>> think anyone actually disables MSI or hypertransport interrupts.
>
> Fair enough, at least for a 2.6.19 kind of release timeframe (and that is 
> what I worry about most, at least right now).
>
>> At this point I have two questions.
>> - What is the easiest path to get us to a stable 2.6.19 where
>>   everything works?
>
> If people don't expect HT and MSI interrupts to be masked (and I can well 
> imagine that), then I think your two-liner patch is good to go. Komuro 
> seems to have acked it already, and in many ways that's the "minimal 
> change" for 2.6.19 right now.

Well I just doubled checked this assertion.  The one driver that uses
the hypertransport irqs doesn't call disable_irq.  On the msi side
at least the forcedeth driver does call disable_irq when in msi mode.

I just doubled checked the historical behavior of the msi code and
it has never done the delayed disable thing.  So not doing it there
is not a regression.

The MSI case is different.  MSI is fundamentally about non-shared
interrupts, and interrupts that don't race with your DMAs.  So with
MSI you don't need a status register read to process the interrupt.

In the context of Ingo's patch I don't like the idea of saddling MSI
interrupts down with the best in class work arounds for a completely
different hardware interrupt model.  Although I don't doubt MSI will
get it's own set of work arounds as we come to know it better.

> I do like Ingo's patch because it seems "safe" (even if I think it might 
> be a bit _overly_ safe), but it changes semantics enough that I don't like 
> it for 2.6.19. Even his second version definitely changes semantics for 
> level-triggered PCI interrupts, even though he fixed ExtInt/i8259 ones.
>
> So I think I'll go with your patch for now, and we can re-visit Ingo's 
> thing after 2.6.19.

Sounds like a plan.

Eric
-
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/