From: Auke Kok <auke-jan.h.kok@intel.com>
To: Stephane Doyon <sdoyon@max-t.com>
Cc: netdev@vger.kernel.org,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
"Cramer, Jeb J" <jeb.j.cramer@intel.com>
Subject: Re: E1000: bug on error path in e1000_probe()
Date: Tue, 01 Aug 2006 11:54:58 -0700 [thread overview]
Message-ID: <44CFA382.7040703@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0607311522200.3139@madrid.max-t.internal>
Stephane Doyon wrote:
> The e1000_probe() function passes references to the netdev structure
> before it's actually registered. In the (admittedly obscure) case where
> the netdev registration fails, we are left with a dangling reference.
>
> Specifically, e1000_probe() calls
> netif_carrier_off(netdev);
> before register_netdev(netdev).
>
> (It also calls pci_set_drvdata(pdev, netdev) rather early, not sure how
> important that is.)
>
> netif_carrier_off() does linkwatch_fire_event(dev);, which in turn does
> dev_hold(dev); and queues up an event with a reference to the netdev.
>
> But the net_device reference counting mechanism only works on registered
> netdevs.
>
> Should the register_netdev() call fail, the error path does
> free_netdev(netdev);, and when the event goes off, it accesses random
> memory through the dangling reference.
>
> I would recommend moving the register_netdev() call earlier.
We agree that this may be an issue and we're looking at how this mis-ordering
entered the code in the first place. I'm probably going to send a patch later
today or include it in this week-worths upstream patches later this week.
We were wondering however how you encountered this problem? Did you see a case
where this race actually happened? it might be an interesting case to look at.
Or did you do this by code review only?
Auke
next prev parent reply other threads:[~2006-08-01 18:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-01 15:16 E1000: bug on error path in e1000_probe() Stephane Doyon
2006-08-01 18:54 ` Auke Kok [this message]
2006-08-01 19:29 ` Stephane Doyon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44CFA382.7040703@intel.com \
--to=auke-jan.h.kok@intel.com \
--cc=jeb.j.cramer@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=netdev@vger.kernel.org \
--cc=sdoyon@max-t.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).