[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1275498007.3915.20.camel@jlt3.sipsolutions.net>
Date: Wed, 02 Jun 2010 19:00:07 +0200
From: Johannes Berg <johannes@...solutions.net>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Greg KH <greg@...ah.com>, netdev <netdev@...r.kernel.org>
Subject: Re: sysfs class/net/ problem
On Wed, 2010-06-02 at 09:43 -0700, Eric W. Biederman wrote:
> > Hmm. I'm also not seeing it with veth, it would seem that ought to be
> > similar?
>
> Since it is the register_netdev path it should be exactly the same.
>
> The big change I made is I in some instances I replaced
> sysfs_remove_link with sysfs_delete_link so I could have enough
> information to infer which network namespace the link was in. Since
> wlan0 is a netdevice all of that information should already be there.
I have no idea :)
> > I don't know if that's happening .. just guessing that it might cause
> > such a problem, and maybe some things are deferred somehow? Since netdev
> > destruction can be deferred, but the wifi sysfs destruction isn't. But
> > then that link there should cause the refcount to not go down until the
> > link goes away>?
>
> unregister_netdevice will defer the final destruction but it does not
> defer netdev_unregister_kobject -> device_del.
>
> What happens if in exit_mac80211_hwsim you call unregister_netdev before
> mac80211_hwsim_free?
>
> At a quick glance it simply looks like you have the ordering reversed in your
> module cleanup, and this is not network namespace related at all.
Nah, the unregister_netdev there removes the "hwsim0" device, while the
mac80211_hwsim_free() will remove all the others, so the ordering of
those two doesn't matter.
johannes
--
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