linux-kernel - Re: [git patch] free

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.1.10.0804240806500.2779@woody.linux-foundation.org>
Date:	Thu, 24 Apr 2008 08:16:53 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Rene Herman <rene.herman@...access.nl>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, rmk@....linux.org.uk,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [git patch] free_irq() fixes

On Thu, 24 Apr 2008, Jeff Garzik wrote:
> 
> Honestly, one thing I was thinking was perhaps a change from
> 
> 	irqreturn_t foo_handler(int irq, void *dev_id)
> to
> 	irqreturn_t foo_handler(struct irq_info *ii, void *dev_id)
> 
> which would IMO make the first parameter useful again, by enabling passing of
> information like MSI message info, or more flexible platform-specific irq info
> that a platform driver may want.  Or direct access to irq_desc or irq_chip
> info.

So I *really* hate that idea. It's much *much* worse than what we have 
now.

Why?

The absolutely _only_ piece of reliably information we have that is 
architecture- and irq-controller neutral is the exact information we pass 
in to "request_irq()". That is: irq number, the name, and the device 
cookie thing. Nothing more.

And of the three things, they have the following pattern:

 - "irq number" is some random cookie, but it is a cookie that the 
   *system* forces on the driver, and that is totally independent of how 
   the irq is delivered or what kind of irq it is (device, system, PCI, 
   ISA, whatever). The driver doesn't get to choose it, but the system and 
   the driver have to agree on it some way (ie regardless of whether it's 
   a PCI driver or a Super-Integrated-bus-of-year-2025, the driver will 
   have to get it from some system resource, ie the pci_dev or whatever)

   IOW, the irq number *does* have meaning, but it is very much by design 
   something that is _purely_ a cookie. You cannot look into it - it's not 
   a pointer to any data.

 - "the name". There really is no point to passing this around, because 
   it's purely for show, and purely so that the generic irq layer can tell 
   the user something in /proc/irq etc. Passing it back to the driver 
   would be entirely pointless, because it is designed purely to be a 
   driver->system informational thing.

 - the "device cookie". This is the thing that the system itself doesn't 
   care about, and is _entirely_ under control of the driver, so the 
   driver can pass its own interrupt controller some helpful instance 
   pointers.

So of the three, "device cookie" is the one that we absolutely have to 
have. The irq number is not necessary, but it does actually have some 
meaning especially for legacy devices (eg ISA), and it is at least 
_sensible_ to pass around (ie it has no downsides, and it's not 
fundamentally broken). And the name would be just stupid.

EVERYTHING else would be architecture-specific. And that is exactly what 
we do not want. EVER. 

Passing in some context that contains bus information is absolutely the 
*last* thing we want. We do not want to have irq handlers that know about 
the interrupt controller details. 

			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/