[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OFD404CD3D.9F15042C-ON802576DD.00595AB8-802576DD.005AD9A8@smsc.com>
Date: Fri, 5 Mar 2010 16:32:03 +0000
From: Steve.Glendinning@...c.com
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] Fix netdev_printk null dereference
David Miller <davem@...emloft.net> wrote on 05/03/2010 15:43:35:
> It seems to me that really you only need this parent NULL check where
> you notice the USB control operation failed and want to print a
> message about that.
>
> That should cover all the necessary cases shouldn't it?
That's the easily reproducible case - during initialisation there are
a lot of register reads and writes, so it's quite easy to trigger by
manually unplugging ~500ms after connection. In this case usbnet is
still in usbnet_probe.
Theoretically though, this device could be disconnected at any time,
and there are other places in the code where we print messages not
triggered by a usb failure (for example set_multicast). Could it
be possibly unsafe to call netdev_printk here?
> Even more importantly, why does a USB disconnect NULL out the netdev
> parent device pointer? Until you actually release this USB device in
> the driver, the parent pointer should stay there.
Most of the time it's not nulled out, and the code succesfully prints
errors as expected, but maybe 1 time in 20 dev.parent is NULL.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists