From: Stanislaw Gruszka <sgruszka@xxxxxxxxxx> Date: Thu, 10 Jan 2013 09:36:42 +0100 > On Wed, Jan 09, 2013 at 11:57:38PM -0800, David Miller wrote: >> From: Stanislaw Gruszka <sgruszka@xxxxxxxxxx> >> Date: Tue, 8 Jan 2013 16:38:51 +0100 >> >> > Since: >> > >> > commit 2c60db037034d27f8c636403355d52872da92f81 >> > Author: Eric Dumazet <edumazet@xxxxxxxxxx> >> > Date: Sun Sep 16 09:17:26 2012 +0000 >> > >> > net: provide a default dev->ethtool_ops >> > >> > wireless core does not correctly assign ethtool_ops. In order to fix >> > the problem, move assignement of default_ethtool_ops to >> > register_netdevice(). This is safe because both register_netdevice() >> > and dev_ethtool() are protected by RTNL lock. >> > >> > Patch is besed on hint of Michał Mirosław. >> > >> > Signed-off-by: Stanislaw Gruszka <sgruszka@xxxxxxxxxx> >> > Cc: stable@xxxxxxxxxxxxxxx # 3.7+ >> > --- >> > v1 -> v2: change order of default_ethtool_ops initialization to avoid >> > the problem. Change the subject accordingly. >> >> I don't understand this. Why is the assignment of default_ethtool_ops >> at netdev allocation time not working? Is wireless really not using >> alloc_netdev*()? > > It does. This is done on individual cfg80211 drivers , i.e. on mac80211 > or full mac drivers. After alloc_netdev*() call, some cfg80211 drivers > provide they own ethtool_ops, but some do not. For them, wireless core > provide generic cfg80211_ethtool_ops, which is assigned in > NETDEV_REGISTER notify call: > > if (!dev->ethtool_ops) > dev->ethtool_ops = &cfg80211_ethtool_ops; > > But after Eric's commit, dev->ethtool_ops is no longer NULL (on cfg80211 > drivers without custom ethtool_ops), but points to &default_ethtool_ops. The whole idea is to remove these kinds of NULL tests against dev->ethtool_ops, thus creating the invariant that given any netdev one must never be able to see a non-NULL value there. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
