linux-kernel - Re: [GIT PULL] irq/core changes for v3.5

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: <alpine.LFD.2.02.1206131127050.3086@ionos>
Date:	Wed, 13 Jun 2012 12:23:09 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] irq/core changes for v3.5

On Wed, 13 Jun 2012, Linus Torvalds wrote:
> I relaize that the current drivers that rely on our old fast-and-loose
> behavior actually *work*, and I realize that apparently there aren't
> any shared irq issues in existence today, but I'd like our generic irq
> code to do the RightThing(tm), and I think that implies that it is the
> drivers that should be fixed, not the core irq layer that should work
> around the problem.

I don't see much of a difference between

  request_threaded_irq(irq, NULL, thread_handler, 0,...)

and

  request_threaded_irq(irq, NULL, thread_handler, IRQF_ONESHOT,...)

The NULL primary handler is a clear indicator for the intention. So
the innocent author of that *correct* driver will see in both cases
what's going on.

But that's a distinction without a difference which we can discuss
forever :)

> Driver authors that see the error should be able to easily fix their
> drivers, no?

No argument about that, though I prefer not to break working stuff
just to add another indicator for something which is obvious already
and requires to have such a weird device on a machine with shared
interrupts.

A 5th option would be to emit a warning in case the flag is not set,
fix it up for now and schedule it for removal in 3.6. Anything what's
not fixed by then is broken for good.

Your choice, really.

Thanks,

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