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
| ||
|
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/
Powered by blists - more mailing lists