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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <480E796E.4070001@garzik.org>
Date:	Tue, 22 Apr 2008 19:49:02 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, rmk@....linux.org.uk
Subject: Re: [git patch] free_irq() fixes

Linus Torvalds wrote:
> 
> On Tue, 22 Apr 2008, Jeff Garzik wrote:
>> (note, for mwave I couldn't use pSettings, since that might fail the ambiguity
>> test)
> 
> Ok, so using the pointer to inside a specific pSettings field is fine.
> 
> But can you also explain to me why that insane driver does this:
> 
> 	 static irqreturn_t UartInterrupt(int irq, void *dev_id)
> 	 {
> 	-       int irqno = (int)(unsigned long) dev_id;
> 	+       unsigned short *irqno = dev_id;
> 		...
> 		*irqno, dev_id);
> 
> instead of just ignoring "dev_id" entirely, and then just using that "irq" 
> argument directly?

That was noted briefly in the push email:

> In my review of every single interrupt handler in the Linux, while
> working on another project (jgarzik/misc-2.6.git#irq-remove), I've
[...]
> Since the #irq-remove project involves removal of the 'irq' argument
> from interrupt handlers (unused 99.8% of the time),
[...]

After going over every irq handler (read: almost every driver in the 
kernel, plus arch code), my #irq-remove branch has confirmed what my gut 
already knew -- the 'irq' argument is completely unused for almost every 
driver.  So I was taking that line of thought as far as it went.

I found less than 10 cases (out of ~1100) that actually did something 
useful with the value _and_ did not have the value already stashed 
somewhere in a reached data structure.

Those cases are easily handled a la pt_regs change -- via a 
get_irqfunc_irq() -- as a quick fix, or the preferred cleanup would be 
to pass info properly via the standard method for passing info to irq 
handlers:  dev_id

	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/