lwn.git/net/mac80211/iface.c, branch docs-4.16

mac80211: only remove AP VLAN frames from TXQ

2017-10-11T07:49:40+00:00

When removing an AP VLAN interface, mac80211 currently purges the entire TXQ for the AP interface. Fix this by using the FQ API introduced in the previous patch to filter frames. Signed-off-by: Johannes Berg Acked-by: Toke Høiland-Jørgensen Signed-off-by: Johannes Berg

mac80211: avoid allocating TXQs that won't be used

2017-09-21T09:41:57+00:00

For AP_VLAN and monitor interfaces we'll never use the TXQs we allocated, so avoid doing so. Signed-off-by: Johannes Berg

mac80211: Fix null pointer dereference with iTXQ support

2017-09-05T09:28:51+00:00

This change adds null pointer check before dereferencing pointer dev on netif_tx_start_all_queues() when an interface is added. With iTXQ support, netif_tx_start_all_queues() is always called while an interface is added. however, the netdev queues are not associated and dev is null when the interface is either NL80211_IFTYPE_P2P_DEVICE or NL80211_IFTYPE_NAN. Signed-off-by: Chunho Lee Signed-off-by: Johannes Berg

mac80211: fix VLAN handling with TXQs

2017-09-05T09:28:43+00:00

With TXQs, the AP_VLAN interfaces are resolved to their owner AP interface when enqueuing the frame, which makes sense since the frame really goes out on that as far as the driver is concerned. However, this introduces a problem: frames to be encrypted with a VLAN-specific GTK will now be encrypted with the AP GTK, since the information about which virtual interface to use to select the key is taken from the TXQ. Fix this by preserving info->control.vif and using that in the dequeue function. This now requires doing the driver-mapping in the dequeue as well. Since there's no way to filter the frames that are sitting on a TXQ, drop all frames, which may affect other interfaces, when an AP_VLAN is removed. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2017-06-15T15:59:32+00:00

The conflicts were two cases of overlapping changes in batman-adv and the qed driver. Signed-off-by: David S. Miller

mac80211: free netdev on dev_alloc_name() error

2017-06-09T19:40:15+00:00

The change to remove free_netdev() from ieee80211_if_free() erroneously didn't add the necessary free_netdev() for when ieee80211_if_free() is called directly in one place, rather than as the priv_destructor. Add the missing call. Fixes: cf124db566e6 ("net: Fix inconsistent teardown and release of private netdev state.") Signed-off-by: Johannes Berg Signed-off-by: David S. Miller

mac80211: manage RX BA session offload without SKB queue

2017-06-08T12:16:29+00:00

Instead of using the SKB queue with the fake pkt_type for the offloaded RX BA session management, also handle this with the normal aggregation state machine worker. This also makes the use of this more reliable since it gets rid of the allocation of the fake skb. Combined with the previous patch, this finally allows us to get rid of the pkt_type hack entirely, so do that as well. Signed-off-by: Johannes Berg

net: Fix inconsistent teardown and release of private netdev state.

2017-06-07T19:53:24+00:00

Network devices can allocate reasources and private memory using netdev_ops->ndo_init(). However, the release of these resources can occur in one of two different places. Either netdev_ops->ndo_uninit() or netdev->destructor(). The decision of which operation frees the resources depends upon whether it is necessary for all netdev refs to be released before it is safe to perform the freeing. netdev_ops->ndo_uninit() presumably can occur right after the NETDEV_UNREGISTER notifier completes and the unicast and multicast address lists are flushed. netdev->destructor(), on the other hand, does not run until the netdev references all go away. Further complicating the situation is that netdev->destructor() almost universally does also a free_netdev(). This creates a problem for the logic in register_netdevice(). Because all callers of register_netdevice() manage the freeing of the netdev, and invoke free_netdev(dev) if register_netdevice() fails. If netdev_ops->ndo_init() succeeds, but something else fails inside of register_netdevice(), it does call ndo_ops->ndo_uninit(). But it is not able to invoke netdev->destructor(). This is because netdev->destructor() will do a free_netdev() and then the caller of register_netdevice() will do the same. However, this means that the resources that would normally be released by netdev->destructor() will not be. Over the years drivers have added local hacks to deal with this, by invoking their destructor parts by hand when register_netdevice() fails. Many drivers do not try to deal with this, and instead we have leaks. Let's close this hole by formalizing the distinction between what private things need to be freed up by netdev->destructor() and whether the driver needs unregister_netdevice() to perform the free_netdev(). netdev->priv_destructor() performs all actions to free up the private resources that used to be freed by netdev->destructor(), except for free_netdev(). netdev->needs_free_netdev is a boolean that indicates whether free_netdev() should be done at the end of unregister_netdevice(). Now, register_netdevice() can sanely release all resources after ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit() and netdev->priv_destructor(). And at the end of unregister_netdevice(), we invoke netdev->priv_destructor() and optionally call free_netdev(). Signed-off-by: David S. Miller

mac80211: fix TX aggregation start/stop callback race

2017-05-30T07:08:40+00:00

When starting or stopping an aggregation session, one of the steps is that the driver calls back to mac80211 that the start/stop can proceed. This is handled by queueing up a fake SKB and processing it from the normal iface/sdata work. Since this isn't flushed when disassociating, the following race is possible: * associate * start aggregation session * driver callback * disassociate * associate again to the same AP * callback processing runs, leading to a WARN_ON() that the TID hadn't requested aggregation If the second association isn't to the same AP, there would only be a message printed ("Could not find station: "), but the same race could happen. Fix this by not going the whole detour with a fake SKB etc. but simply looking up the aggregation session in the driver callback, marking it with a START_CB/STOP_CB bit and then scheduling the regular aggregation work that will now process these bits as well. This also simplifies the code and gets rid of the whole problem with allocation failures of said skb, which could have left the session in limbo. Reported-by: Jouni Malinen Signed-off-by: Johannes Berg

Merge tag 'mac80211-next-for-davem-2017-04-18' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next

2017-04-20T17:54:40+00:00

Johannes Berg says: ==================== My last pull request has been a while, we now have: * connection quality monitoring with multiple thresholds * support for FILS shared key authentication offload * pre-CAC regulatory compliance - only ETSI allows this * sanity check for some rate confusion that hit ChromeOS (but nobody else uses it, evidently) * some documentation updates * lots of cleanups ==================== Signed-off-by: David S. Miller