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: <4810A9E6.1080201@garzik.org>
Date:	Thu, 24 Apr 2008 11:40:22 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.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

Linus Torvalds wrote:
> 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.

Agreed.

However, it does not follow that an int is what _must_ be passed around. 
  We already have design patterns like

	cookie_pointer = ioremap(raw bus resource)

Not that I am the one pushing for that, just noting.

Overall this is all wild-assed speculation based on a thought 
exploration (#irq-remove) that a several kernel hackers seemed to like.

>  - 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.

Agreed.

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

Not true -- you have metadata/OOB data like MSI messages, where you are 
passed a value from the PCI hardware in the PCI message, not just an 
"interrupt asserted" condition.  Or s/value/values/ if you enable PCI 
MSI's multiple message support.

The PCI devices themselves are moving from sending a single bit of 
information ("irq!") to sending actual messages.

That is not arch-specific at all, but a new model for "interrupt" (i.e. 
event) notification being pushed upon us.

	Jeff

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