linux-kernel - Re: IRQF_DISABLED problem

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]

Date:	Thu, 26 Jul 2007 16:04:42 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
cc:	matthew@....cx, mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: IRQF_DISABLED problem



On Thu, 26 Jul 2007, David Miller wrote:
> > 
> > Another possibility is to force it if *any* of the handlers want
> > IRQF_DISABLED.  This seems to work:
> 
> Yes, this is consistent with how we handle sharing, we should
> enforce that all the flags on the chain are compatible.

No. It's no better than the current situation.

There are really a few choices:

 (a) Keep it like we always have.  What's the downside, really? It's what 
     we've got, it's what is tested.

 (b) Enforce that flags match. This may sound logical, but it will 
     actually *break* existing setups, because tons of drivers set 
     IRQF_DISABLED for no good reason (probably all totally historical)

 (c) "one IRQF_DISABLED means that everything runs disabled". This is 
     quite possibly buggy. There have been SCSI drivers with timeout 
     behaviour where they actually wait for timers to happen while in 
     their irq handlers. Bad form, and I *hope* we've fixed them all, but 
     I distinctly remember it being important that the timer had higher 
     priority than some SCSI drivers on some architecture.

 (d) "one !IRFQ_DISABLED means that everything runs with irq's on". I 
     don't think it's any better than the other behaviour.

 (e) Just ignore IRQF_DISABLED entirely when mixed with IRQF_SHARED, 
     because they're all pretty much guaranteed to be legacy and buggy and 
     pointless.

 (f) Disable and re-enable interrupts per handler.

Quite frankly, my preference would be (a) followed by (e) or (f), and 
(b)-(d) are in my opinion the worst of the lot with no upsides at all (and 
(b) in particular is pretty much _guaranteed_ to break existing setups).

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