linux-toradex.git/net/mac80211/iface.c, branch v3.10.40

mac80211: close AP_VLAN interfaces before unregistering all

2013-07-25T21:07:31+00:00

commit 4c8a9d4bfaf7dbc7d2168494904d79d22cc01db7 upstream.

Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces")
there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
up. If the AP_VLAN interface was registered after the AP it belongs
to (which is the typical case) and then we get into this code path,
unregister_netdevice_many() will crash because it isn't prepared to
deal with interfaces being closed in the middle of it. Exactly this
happens though, because we iterate the list, find the AP master this
AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
unregister_netdevice_many() won't pick up the fact that the AP_VLAN
is already down and will do it again, causing a crash.

Signed-off-by: Johannes Berg 
Cc: Eric Dumazet 
Signed-off-by: Greg Kroah-Hartman

mac80211: Allow single vif mac address change with addr_mask

2013-05-27T09:26:48+00:00

When changing the MAC address of a single vif mac80211 will check if
the new address fits into the address mask specified by the driver.
This only needs to be done when using multiple BSSIDs. Hence, check
the new address only against all other vifs.

Also fix the MAC address assignment on new interfaces if the user
changed the address of a vif such that perm_addr is not covered by
addr_mask anymore.

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=57371

Signed-off-by: Helmut Schaa 
Signed-off-by: Jakub Kicinski 
Reported-by: Alessandro Lannocca 
Cc: Alessandro Lannocca 
Cc: Bruno Randolf 
Signed-off-by: Johannes Berg

mac80211: close AP_VLAN interfaces before unregistering all

2013-05-27T09:26:47+00:00

Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces")
there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
up. If the AP_VLAN interface was registered after the AP it belongs
to (which is the typical case) and then we get into this code path,
unregister_netdevice_many() will crash because it isn't prepared to
deal with interfaces being closed in the middle of it. Exactly this
happens though, because we iterate the list, find the AP master this
AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
unregister_netdevice_many() won't pick up the fact that the AP_VLAN
is already down and will do it again, causing a crash.

Cc: stable@vger.kernel.org [2.6.33+]
Cc: Eric Dumazet 
Signed-off-by: Johannes Berg

mac80211: assign AP_VLAN hw queues correctly

2013-05-27T09:26:47+00:00

A lot of code in mac80211 assumes that the hw queues are
set up correctly for all interfaces (except for monitor)
but this isn't true for AP_VLAN interfaces. Fix this by
copying the AP master configuration when an AP VLAN is
brought up, after this the AP interface can't change its
configuration any more and needs to be brought down to
change it, which also forces AP_VLAN interfaces down, so
just copying in open() is sufficient.

Reported-by: Jouni Malinen 
Signed-off-by: Johannes Berg

mac80211: fix queue handling crash

2013-05-23T19:04:38+00:00

The code I added in "mac80211: don't start new netdev queues
if driver stopped" crashes for monitor and AP VLAN interfaces
because while they have a netdev, they don't have queues set
up by the driver.

To fix the crash, exclude these from queue accounting here
and just start their netdev queues unconditionally.

For monitor, this is the best we can do, as we can redirect
frames there to any other interface and don't know which one
that will since it can be different for each frame.

For AP VLAN interfaces, we can do better later and actually
properly track the queue status. Not doing this is really a
separate bug though.

Reported-by: Ilan Peer 
Reported-by: Jouni Malinen 
Signed-off-by: Johannes Berg

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless

2013-04-23T18:09:39+00:00

Conflicts:
	drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c

mac80211: use synchronize_rcu() with rcu_barrier()

2013-04-22T13:40:39+00:00

The RCU docs used to state that rcu_barrier() included a wait
for an RCU grace period; however the comments for rcu_barrier()
as of commit f0a0e6f... "rcu: Clarify memory-ordering properties
of grace-period primitives" contradict this.

So add back synchronize_{rcu,net}() to where they once were,
but keep the rcu_barrier()s for the call_rcu() callbacks.

Cc: stable 
Signed-off-by: Bob Copeland 
Reviewed-by: Paul E. McKenney 
Signed-off-by: Johannes Berg

Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next

2013-04-10T18:09:54+00:00

Conflicts:
	drivers/net/wireless/ath/carl9170/debug.c
	drivers/net/wireless/ath/carl9170/main.c
	net/mac80211/ieee80211_i.h

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless

2013-04-10T13:31:39+00:00

Conflicts:
	drivers/net/wireless/rt2x00/rt2x00pci.c

mac80211: fix LED in idle handling

2013-04-08T11:12:05+00:00

feng xiangjun reports that my

commit 382a103b2b528a3085cde4ac56fc69d92a828b72
Author: Johannes Berg 
Date:   Fri Mar 22 22:30:09 2013 +0100

    mac80211: fix idle handling sequence

broke the wireless status LED. The reason is that
we now call ieee80211_idle_off() when the channel
context is assigned, and that doesn't recalculate
the LED state. Fix this by making that function a
wrapper around most of idle recalculation while
forcing active.

Reported-by: feng xiangjun 
Tested-by: feng xiangjun 
Signed-off-by: Johannes Berg