linux/net, branch v3.9.1

wireless: regulatory: fix channel disabling race condition

2013-05-08T03:33:13Z

commit 990de49f74e772b6db5208457b7aa712a5f4db86 upstream. When a full scan 2.4 and 5 GHz scan is scheduled, but then the 2.4 GHz part of the scan disables a 5.2 GHz channel due to, e.g. receiving country or frequency information, that 5.2 GHz channel might already be in the list of channels to scan next. Then, when the driver checks if it should do a passive scan, that will return false and attempt an active scan. This is not only wrong but can also lead to the iwlwifi device firmware crashing since it checks regulatory as well. Fix this by not setting the channel flags to just disabled but rather OR'ing in the disabled flag. That way, even if the race happens, the channel will be scanned passively which is still (mostly) correct. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: use synchronize_rcu() with rcu_barrier()

2013-05-08T03:33:05Z

commit 8ceb59557bdc373e532b87d4142ce27e04218f0e upstream. 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. Signed-off-by: Bob Copeland Reviewed-by: Paul E. McKenney Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: fix station entry leak/warning while suspending

2013-05-08T03:33:04Z

commit b20d34c458bc2bbd0a4624f2933581e01e72d875 upstream. Since Stanislaw's patches, when suspending while connected, cfg80211 will disconnect. This causes the AP station to be removed, which uses call_rcu() to clean up. Due to needing process context, this queues a work struct on the mac80211 workqueue. This will warn and fail when already suspended, which can happen if the rcu call doesn't happen quickly. To fix this, replace the synchronize_net() which is really just synchronize_rcu_expedited() with rcu_barrier(), which unlike synchronize_rcu() waits until RCU callback have run and thus avoids this issue. In theory, this can even happen without Stanislaw's change to disconnect on suspend since userspace might disconnect just before suspending, though then it's unlikely that the call_rcu() will be delayed long enough. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

net: rate-limit warn-bad-offload splats.

2013-04-19T21:57:49Z

If one does do something unfortunate and allow a bad offload bug into the kernel, this the skb_warn_bad_offload can effectively live-lock the system, filling the logs with the same error over and over. Add rate limitation to this so that box remains otherwise functional in this case. Signed-off-by: Ben Greear Signed-off-by: David S. Miller

pkt_sched: fix error return code in fw_change_attrs()

2013-04-19T21:34:53Z

Fix to return -EINVAL when tb[TCA_FW_MASK] is set and head->mask != 0xFFFFFFFF instead of 0 (ifdef CONFIG_NET_CLS_IND and tb[TCA_FW_INDEV]), as done elsewhere in this function. Signed-off-by: Wei Yongjun Signed-off-by: Jamal Hadi Salim Signed-off-by: David S. Miller

irda: small read past the end of array in debug code

2013-04-19T21:32:31Z

The "reason" can come from skb->data[] and it hasn't been capped so it can be from 0-255 instead of just 0-6. For example in irlmp_state_dtr() the code does: reason = skb->data[3]; ... irlmp_disconnect_indication(self, reason, skb); Also LMREASON has a couple other values which don't have entries in the irlmp_reasons[] array. And 0xff is a valid reason as well which means "unknown". So far as I can see we don't actually care about "reason" except for in the debug code. Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf

2013-04-19T18:24:47Z

Pablo Neira Ayuso says: ==================== If time allows, please consider pulling the following patchset contains two late Netfilter fixes, they are: * Skip broadcast/multicast locally generated traffic in the rpfilter, (closes netfilter bugzilla #814), from Florian Westphal. * Fix missing elements in the listing of ipset bitmap ip,mac set type with timeout support enabled, from Jozsef Kadlecsik. ==================== Signed-off-by: David S. Miller

Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless

2013-04-19T18:23:55Z

John W. Linville says: ==================== A few stragglers hoping for 3.9, somewhat delayed due to my travels... On the mac80211 bits, Johannes says: "Sadly, I have another pull request -- the idle handling fix broke LED handling in some cases." and: "Yet one more! This fixes a fairly important/annoying bug -- when roaming between multiple APs of the same network, the system could get stuck thinking it was connected to the old one while it really wasn't." On top of that... Arend sends a brcmfmac patch that removes advertising a feature that isn't actually fully supported, and a brcmsmac patch that rearranges code to request firmware at IFF_UP to play more nicely with being built into the kernel. Felix gives us a minor ath9k_htc fix to support the newly released open source firmware, and an ath9k_hw initvals fix to improve device stability. Rafał Miłecki provides a fix for an ssb regression that caused a serious performance problem with b43. Zefir Kurtisi offers an ath9k fix to change some kmalloc flags to allow the DFS detector to be called in softirq context. Please let me know if there are problems. If these don't make 3.9, I'll just pull them into wireless-next -- just let me know if you want to do it that way! ==================== Signed-off-by: David S. Miller

tcp: call tcp_replace_ts_recent() from tcp_ack()

2013-04-19T18:21:53Z

commit bd090dfc634d (tcp: tcp_replace_ts_recent() should not be called from tcp_validate_incoming()) introduced a TS ecr bug in slow path processing. 1 A > B P. 1:10001(10000) ack 1 2 B < A . 1:1(0) ack 1 win 257 3 A > B . 1:1001(1000) ack 1 win 227 4 A > B . 1001:2001(1000) ack 1 win 227 (ecr 200 should be ecr 300 in packets 3 & 4) Problem is tcp_ack() can trigger send of new packets (retransmits), reflecting the prior TSval, instead of the TSval contained in the currently processed incoming packet. Fix this by calling tcp_replace_ts_recent() from tcp_ack() after the checks, but before the actions. Reported-by: Yuchung Cheng Signed-off-by: Eric Dumazet Cc: Neal Cardwell Acked-by: Neal Cardwell Signed-off-by: David S. Miller

netfilter: xt_rpfilter: skip locally generated broadcast/multicast, too

2013-04-18T22:11:59Z

Alex Efros reported rpfilter module doesn't match following packets: IN=br.qemu SRC=192.168.2.1 DST=192.168.2.255 [ .. ] (netfilter bugzilla #814). Problem is that network stack arranges for the locally generated broadcasts to appear on the interface they were sent out, so the IFF_LOOPBACK check doesn't trigger. As -m rpfilter is restricted to PREROUTING, we can check for existing rtable instead, it catches locally-generated broad/multicast case, too. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso