linux-kernel - Re: [PATCH][RESEND] Semi-pointless NULL test in uli526x driver

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] [day] [month] [year] [list]

Message-ID: <46B8E4EB.1040208@garzik.org>
Date:	Tue, 07 Aug 2007 17:32:27 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Jesper Juhl <jesper.juhl@...il.com>,
	Kyle McMartin <kyle@...artin.ca>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Valerie Henson <val@....edu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	tulip-users@...ts.sourceforge.net, david@...g.hm,
	Grant Grundler <grundler@...isc-linux.org>,
	Michael Buesch <mb@...sch.de>,
	"John W. Linville" <linville@...driver.com>
Subject: Re: [PATCH][RESEND] Semi-pointless NULL test in uli526x driver

Jesper Juhl wrote:
> On 07/08/07, Jeff Garzik <jeff@...zik.org> wrote:
>> Jesper Juhl wrote:
>>> (resending previously submitted patch from 16/7-2007 22:40)
>>>
>>>
>>> Hi,
>>>
>>> In drivers/net/tulip/uli526x.c::uli526x_interrupt() there's a test
>>> of the function argument 'void *dev_id' against NULL. But that
>>> test is pretty pointless, since if ever 'dev_id' is NULL we'll
>>> already have crashed inside "netdev_priv(dev)".
>>>
>>> I don't think dev_id can ever actually be NULL, so the whole block
>>> inside "if (!dev) {" could probably just go away. But I guess
>>> there's a good reason someone put that ULI526X_DBUG() in there - and
>>> if 'dev_id' /can/ actually be NULL then it's nice to have and in
>>> that case this patch actually fixes a possible crash (hence the
>>> version number update).
>>> So I guess that in this case we should just move the
>>> "db = netdev_priv(dev)" assignment past that NULL test. That's what
>>> this patch does.
>>>
>>> Found by the Coverity checker.
>>> Compile tested.
>>>
>>>
>>> PS. Please keep me on Cc when replying.
>>>
>>>
>>> Signed-off-by: Jesper Juhl <jesper.juhl@...il.com>
>> Just remove the dev==NULL test...
>>
> 
> Hmm, it would seem there's some disagreement about that :
> 
> On 04/08/07, Kyle McMartin <kyle@...artin.ca> wrote:
> ...
>> It *can* be null, in the case of another handler being registered on the
>> same irq number, passing NULL for the cookie.
>>
>> Ack. Will apply.
>>
>> Regards,
>>         Kyle
>>
> 
> I'll let you and Kyle fight it out :-)


My official opinion (for net drivers and ATA at least):  It is pointless 
having such a check in the hottest of driver hot paths, since a large 
majority of drivers do not have such a check.

It is better to fix the extremely rare oddball that passes NULL to 
request_irq(), than to update all drivers to be slower due to the oddballs.

	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/