From: Johannes Berg <johannes@sipsolutions.net>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] net: Fix inconsistent teardown and release of private netdev state.
Date: Fri, 09 Jun 2017 16:33:47 +0200 [thread overview]
Message-ID: <1497018827.12088.1.camel@sipsolutions.net> (raw)
In-Reply-To: <20170609.101733.1675759409997288763.davem@davemloft.net>
On Fri, 2017-06-09 at 10:17 -0400, David Miller wrote:
>
> > I guess this must mean that that all others are dealing with the
> > problem "manually", right? Perhaps needs_free_netdev isn't all that
> > necessary then?
>
> Yeah, the major two modes of operation are manual freeing of the
> netdev (usually at module unload time or similar) or via the
> destructor mechanisms.
Ok, thanks.
> > I think you introduced a bug though - isn't this needed?
> >
> > --- a/net/mac80211/iface.c
> > +++ b/net/mac80211/iface.c
> > @@ -1816,6 +1816,7 @@ int ieee80211_if_add(struct ieee80211_local
> *local, const char *name,
> > ret = dev_alloc_name(ndev, ndev->name);
> > if (ret < 0) {
> > ieee80211_if_free(ndev);
> > + free_netdev(ndev);
> > return ret;
> > }
> >
> > There was another caller of ieee80211_if_free() which you modified,
> and
> > thus needs the free_netdev() that you removed from it.
>
> I think you are right. The pattern is that when something fails
> after allocating the netdev, but before registering it, that code
> must free the netdev itself.
Right. Do you want me to put that into my tree? I could do it tonight,
or perhaps only Monday though.
> > Would an alternative have been to not use (priv_)destructor here,
> and
> > just free all the data after unregister_netdevice(_many)? This sets
> the
> > reg_state to NETREG_UNREGISTERING, so sysfs can no longer look at
> the
> > stats afterwards, and it's been unlisted (unlist_netdevice) so
> can't be
> > reached through any other means either.
> >
> > IOW, this would also work and fix the bug above along the way?
> >
> > diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
> > index 915d7e1b4545..23df973d5181 100644
> > --- a/net/mac80211/iface.c
> > +++ b/net/mac80211/iface.c
> ...
> > @@ -1932,6 +1931,7 @@ void ieee80211_if_remove(struct
> ieee80211_sub_if_data *sdata)
> >
> > if (sdata->dev) {
> > unregister_netdevice(sdata->dev);
> > + ieee80211_if_free(sdata->dev);
> > } else {
> > cfg80211_unregister_wdev(&sdata->wdev);
> > ieee80211_teardown_sdata(sdata);
>
> Unless I misunderstood something, unregister_netdevice() here will
> invoke the ->priv_destructor() and thus now it will be invoked twice?
I think you missed that I removed priv_destructor?
johannes
next prev parent reply other threads:[~2017-06-09 14:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-07 19:54 [PATCH] net: Fix inconsistent teardown and release of private netdev state David Miller
2017-06-09 12:45 ` Johannes Berg
2017-06-09 14:17 ` David Miller
2017-06-09 14:33 ` Johannes Berg [this message]
2017-06-09 17:14 ` David Miller
2017-06-09 17:21 ` Stephen Hemminger
2017-06-09 18:54 ` David Miller
2017-06-12 20:40 ` Stephen Hemminger
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=1497018827.12088.1.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/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).