linux/net, branch v3.10.10

NFC: llcp: Fix non blocking sockets connections

2013-08-29T16:47:30Z

commit b4011239a08e7e6c2c6e970dfa9e8ecb73139261 upstream. Without the new LLCP_CONNECTING state, non blocking sockets will be woken up with a POLLHUP right after calling connect() because their state is stuck at LLCP_CLOSED. That prevents userspace from implementing any proper non blocking socket based NFC p2p client. Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman

mac80211: don't wait for TX status forever

2013-08-29T16:47:29Z

commit cb236d2d713cff83d024a82b836757d9e2b50715 upstream. TX status notification can get lost, or the frames could get stuck on the queue, so don't wait for the callback from the driver forever and instead time out after half a second. Signed-off-by: Johannes Berg Signed-off-by: Luciano Coelho Signed-off-by: Greg Kroah-Hartman

Revert "genetlink: fix family dump race"

2013-08-20T22:32:57Z

This reverts commit aab4f8d490ef8c184d854d5f630438c10406765c, commit 58ad436fcf49810aa006016107f494c9ac9013db upstream, as it causes problems. Cc: Johannes Berg Cc: Andrei Otcheretianski Cc: David S. Miller Signed-off-by: Greg Kroah-Hartman

nl80211: fix another nl80211_fam.attrbuf race

2013-08-20T15:43:04Z

commit c319d50bfcf678c2857038276d9fab3c6646f3bf upstream. This is similar to the race Linus had reported, but in this case it's an older bug: nl80211_prepare_wdev_dump() uses the wiphy index in cb->args[0] as it is and thus parses the message over and over again instead of just once because 0 is the first valid wiphy index. Similar code in nl80211_testmode_dump() correctly offsets the wiphy_index by 1, do that here as well. Reported-by: Ben Hutchings Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

cfg80211: fix P2P GO interface teardown

2013-08-20T15:43:03Z

commit 74418edec915d0f446debebde08d170c7b8ba0ee upstream. When a P2P GO interface goes down, cfg80211 doesn't properly tear it down, leading to warnings later. Add the GO interface type to the enumeration to tear it down like AP interfaces. Otherwise, we leave it pending and mac80211's state can get very confused, leading to warnings later. Reported-by: Ilan Peer Tested-by: Ilan Peer Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

genetlink: fix family dump race

2013-08-20T15:43:03Z

commit 58ad436fcf49810aa006016107f494c9ac9013db upstream. When dumping generic netlink families, only the first dump call is locked with genl_lock(), which protects the list of families, and thus subsequent calls can access the data without locking, racing against family addition/removal. This can cause a crash. Fix it - the locking needs to be conditional because the first time around it's already locked. A similar bug was reported to me on an old kernel (3.4.47) but the exact scenario that happened there is no longer possible, on those kernels the first round wasn't locked either. Looking at the current code I found the race described above, which had also existed on the old kernel. Reported-by: Andrei Otcheretianski Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

mac80211: continue using disabled channels while connected

2013-08-20T15:43:03Z

commit ddfe49b42d8ad4bfdf92d63d4a74f162660d878d upstream. In case the AP has different regulatory information than we do, it can happen that we connect to an AP based on e.g. the world roaming regulatory data, and then update our database with the AP's country information disables the channel the AP is using. If this happens on an HT AP, the bandwidth tracking code will hit the WARN_ON() and disconnect. Since that's not very useful, ignore the channel-disable flag in bandwidth tracking. Reported-by: Chris Wright Tested-by: Chris Wright Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: fix infinite loop in ieee80211_determine_chantype

2013-08-20T15:43:03Z

commit b56e4b857c5210e848bfb80e074e5756a36cd523 upstream. Commit "3d9646d mac80211: fix channel selection bug" introduced a possible infinite loop by moving the out target above the chandef_downgrade while loop. When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump back up to re-run the while loop...indefinitely. Replace goto with break and carry on. This may not be sufficient to connect to the AP, but will at least keep the cpu from livelocking. Thanks to Derek Atkins as an extra pair of debugging eyes. Signed-off-by: Chris Wright Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: ignore HT primary channel while connected

2013-08-20T15:43:03Z

commit 5cdaed1e878d723d56d04ae0be1738124acf9f46 upstream. While we're connected, the AP shouldn't change the primary channel in the HT information. We checked this, and dropped the connection if it did change it. Unfortunately, this is causing problems on some APs, e.g. on the Netgear WRT610NL: the beacons seem to always contain a bad channel and if we made a connection using a probe response (correct data) we drop the connection immediately and can basically not connect properly at all. Work around this by ignoring the HT primary channel information in beacons if we're already connected. Also print out more verbose messages in the other situations to help diagnose similar bugs quicker in the future. Acked-by: Andy Isaacson Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

SUNRPC: If the rpcbind channel is disconnected, fail the call to unregister

2013-08-15T05:59:08Z

commit 786615bc1ce84150ded80daea6bd9f6297f48e73 upstream. If rpcbind causes our connection to the AF_LOCAL socket to close after we've registered a service, then we want to be careful about reconnecting since the mount namespace may have changed. By simply refusing to reconnect the AF_LOCAL socket in the case of unregister, we avoid the need to somehow save the mount namespace. While this may lead to some services not unregistering properly, it should be safe. Signed-off-by: Trond Myklebust Cc: Nix Cc: Jeff Layton Signed-off-by: Greg Kroah-Hartman