LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH][RESEND] Semi-pointless NULL test in uli526x driver
@ 2007-08-04 18:32 Jesper Juhl
  2007-08-04 21:14 ` Kyle McMartin
  2007-08-07 21:23 ` Jeff Garzik
  0 siblings, 2 replies; 5+ messages in thread
From: Jesper Juhl @ 2007-08-04 18:32 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Valerie Henson, Linux Kernel Mailing List, tulip-users,
	Jesper Juhl, Kyle McMartin, david, Grant Grundler, Jeff Garzik

(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@gmail.com>
---

 drivers/net/tulip/uli526x.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
index ca2548e..3df2376 100644
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -13,8 +13,8 @@
 */
 
 #define DRV_NAME	"uli526x"
-#define DRV_VERSION	"0.9.3"
-#define DRV_RELDATE	"2005-7-29"
+#define DRV_VERSION	"0.9.4"
+#define DRV_RELDATE	"2007-7-16"
 
 #include <linux/module.h>
 
@@ -662,7 +662,7 @@ static int uli526x_stop(struct net_device *dev)
 static irqreturn_t uli526x_interrupt(int irq, void *dev_id)
 {
 	struct net_device *dev = dev_id;
-	struct uli526x_board_info *db = netdev_priv(dev);
+	struct uli526x_board_info *db;
 	unsigned long ioaddr = dev->base_addr;
 	unsigned long flags;
 
@@ -670,6 +670,7 @@ static irqreturn_t uli526x_interrupt(int irq, void *dev_id)
 		ULI526X_DBUG(1, "uli526x_interrupt() without DEVICE arg", 0);
 		return IRQ_NONE;
 	}
+	db = netdev_priv(dev);
 
 	spin_lock_irqsave(&db->lock, flags);
 	outl(0, ioaddr + DCR7);



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH][RESEND] Semi-pointless NULL test in uli526x driver
  2007-08-04 18:32 [PATCH][RESEND] Semi-pointless NULL test in uli526x driver Jesper Juhl
@ 2007-08-04 21:14 ` Kyle McMartin
  2007-08-07 21:23 ` Jeff Garzik
  1 sibling, 0 replies; 5+ messages in thread
From: Kyle McMartin @ 2007-08-04 21:14 UTC (permalink / raw)
  To: Jesper Juhl
  Cc: Andrew Morton, Valerie Henson, Linux Kernel Mailing List,
	tulip-users, david, Grant Grundler, Jeff Garzik

On Sat, Aug 04, 2007 at 08:32:12PM +0200, Jesper Juhl wrote:
> 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). 

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH][RESEND] Semi-pointless NULL test in uli526x driver
  2007-08-04 18:32 [PATCH][RESEND] Semi-pointless NULL test in uli526x driver Jesper Juhl
  2007-08-04 21:14 ` Kyle McMartin
@ 2007-08-07 21:23 ` Jeff Garzik
  2007-08-07 21:28   ` Jesper Juhl
  1 sibling, 1 reply; 5+ messages in thread
From: Jeff Garzik @ 2007-08-07 21:23 UTC (permalink / raw)
  To: Jesper Juhl
  Cc: Andrew Morton, Valerie Henson, Linux Kernel Mailing List,
	tulip-users, Kyle McMartin, david, Grant Grundler

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@gmail.com>

Just remove the dev==NULL test...

Thanks,

	Jeff




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH][RESEND] Semi-pointless NULL test in uli526x driver
  2007-08-07 21:23 ` Jeff Garzik
@ 2007-08-07 21:28   ` Jesper Juhl
  2007-08-07 21:32     ` Jeff Garzik
  0 siblings, 1 reply; 5+ messages in thread
From: Jesper Juhl @ 2007-08-07 21:28 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Andrew Morton, Valerie Henson, Linux Kernel Mailing List,
	tulip-users, Kyle McMartin, david, Grant Grundler

On 07/08/07, Jeff Garzik <jeff@garzik.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@gmail.com>
>
> Just remove the dev==NULL test...
>

Hmm, it would seem there's some disagreement about that :

On 04/08/07, Kyle McMartin <kyle@mcmartin.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 :-)

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH][RESEND] Semi-pointless NULL test in uli526x driver
  2007-08-07 21:28   ` Jesper Juhl
@ 2007-08-07 21:32     ` Jeff Garzik
  0 siblings, 0 replies; 5+ messages in thread
From: Jeff Garzik @ 2007-08-07 21:32 UTC (permalink / raw)
  To: Jesper Juhl, Kyle McMartin
  Cc: Andrew Morton, Valerie Henson, Linux Kernel Mailing List,
	tulip-users, david, Grant Grundler, Michael Buesch,
	John W. Linville

Jesper Juhl wrote:
> On 07/08/07, Jeff Garzik <jeff@garzik.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@gmail.com>
>> Just remove the dev==NULL test...
>>
> 
> Hmm, it would seem there's some disagreement about that :
> 
> On 04/08/07, Kyle McMartin <kyle@mcmartin.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



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-08-07 21:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-08-04 18:32 [PATCH][RESEND] Semi-pointless NULL test in uli526x driver Jesper Juhl
2007-08-04 21:14 ` Kyle McMartin
2007-08-07 21:23 ` Jeff Garzik
2007-08-07 21:28   ` Jesper Juhl
2007-08-07 21:32     ` Jeff Garzik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).