From: Greg Kroah-Hartman Date: Fri, 16 Aug 2013 20:21:46 +0000 (-0700) Subject: 3.10-stable patches X-Git-Tag: v3.0.92~19 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ad0c7dd3f00e111ba1244df103c3f7aa2b2b5360;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: can-pcan_usb-fix-wrong-memcpy-bytes-length.patch genetlink-fix-family-dump-race.patch iwl4965-reset-firmware-after-rfkill-off.patch iwl4965-set-power-mode-early.patch mac80211-continue-using-disabled-channels-while-connected.patch mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch mac80211-ignore-ht-primary-channel-while-connected.patch --- diff --git a/queue-3.10/can-pcan_usb-fix-wrong-memcpy-bytes-length.patch b/queue-3.10/can-pcan_usb-fix-wrong-memcpy-bytes-length.patch new file mode 100644 index 00000000000..65a021933c6 --- /dev/null +++ b/queue-3.10/can-pcan_usb-fix-wrong-memcpy-bytes-length.patch @@ -0,0 +1,35 @@ +From 3c322a56b01695df15c70bfdc2d02e0ccd80654e Mon Sep 17 00:00:00 2001 +From: Stephane Grosjean +Date: Fri, 9 Aug 2013 11:44:06 +0200 +Subject: can: pcan_usb: fix wrong memcpy() bytes length + +From: Stephane Grosjean + +commit 3c322a56b01695df15c70bfdc2d02e0ccd80654e upstream. + +Fix possibly wrong memcpy() bytes length since some CAN records received from +PCAN-USB could define a DLC field in range [9..15]. +In that case, the real DLC value MUST be used to move forward the record pointer +but, only 8 bytes max. MUST be copied into the data field of the struct +can_frame object of the skb given to the network core. + +Signed-off-by: Stephane Grosjean +Signed-off-by: Marc Kleine-Budde +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/can/usb/peak_usb/pcan_usb.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/can/usb/peak_usb/pcan_usb.c ++++ b/drivers/net/can/usb/peak_usb/pcan_usb.c +@@ -649,7 +649,7 @@ static int pcan_usb_decode_data(struct p + if ((mc->ptr + rec_len) > mc->end) + goto decode_failed; + +- memcpy(cf->data, mc->ptr, rec_len); ++ memcpy(cf->data, mc->ptr, cf->can_dlc); + mc->ptr += rec_len; + } + diff --git a/queue-3.10/genetlink-fix-family-dump-race.patch b/queue-3.10/genetlink-fix-family-dump-race.patch new file mode 100644 index 00000000000..0a4a73798aa --- /dev/null +++ b/queue-3.10/genetlink-fix-family-dump-race.patch @@ -0,0 +1,54 @@ +From 58ad436fcf49810aa006016107f494c9ac9013db Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Tue, 13 Aug 2013 09:04:05 +0200 +Subject: genetlink: fix family dump race + +From: Johannes Berg + +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 + +--- + net/netlink/genetlink.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/net/netlink/genetlink.c ++++ b/net/netlink/genetlink.c +@@ -789,6 +789,10 @@ static int ctrl_dumpfamily(struct sk_buf + struct net *net = sock_net(skb->sk); + int chains_to_skip = cb->args[0]; + int fams_to_skip = cb->args[1]; ++ bool need_locking = chains_to_skip || fams_to_skip; ++ ++ if (need_locking) ++ genl_lock(); + + for (i = chains_to_skip; i < GENL_FAM_TAB_SIZE; i++) { + n = 0; +@@ -810,6 +814,9 @@ errout: + cb->args[0] = i; + cb->args[1] = n; + ++ if (need_locking) ++ genl_unlock(); ++ + return skb->len; + } + diff --git a/queue-3.10/iwl4965-reset-firmware-after-rfkill-off.patch b/queue-3.10/iwl4965-reset-firmware-after-rfkill-off.patch new file mode 100644 index 00000000000..31885420638 --- /dev/null +++ b/queue-3.10/iwl4965-reset-firmware-after-rfkill-off.patch @@ -0,0 +1,56 @@ +From 788f7a56fce1bcb2067b62b851a086fca48a0056 Mon Sep 17 00:00:00 2001 +From: Stanislaw Gruszka +Date: Thu, 1 Aug 2013 12:07:55 +0200 +Subject: iwl4965: reset firmware after rfkill off + +From: Stanislaw Gruszka + +commit 788f7a56fce1bcb2067b62b851a086fca48a0056 upstream. + +Using rfkill switch can make firmware unstable, what cause various +Microcode errors and kernel warnings. Reseting firmware just after +rfkill off (radio on) helped with that. + +Resolve: +https://bugzilla.redhat.com/show_bug.cgi?id=977053 + +Reported-and-tested-by: Justin Pearce +Signed-off-by: Stanislaw Gruszka +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/iwlegacy/4965-mac.c | 10 +++++----- + drivers/net/wireless/iwlegacy/common.c | 1 + + 2 files changed, 6 insertions(+), 5 deletions(-) + +--- a/drivers/net/wireless/iwlegacy/4965-mac.c ++++ b/drivers/net/wireless/iwlegacy/4965-mac.c +@@ -4442,12 +4442,12 @@ il4965_irq_tasklet(struct il_priv *il) + * is killed. Hence update the killswitch state here. The + * rfkill handler will care about restarting if needed. + */ +- if (!test_bit(S_ALIVE, &il->status)) { +- if (hw_rf_kill) +- set_bit(S_RFKILL, &il->status); +- else +- clear_bit(S_RFKILL, &il->status); ++ if (hw_rf_kill) { ++ set_bit(S_RFKILL, &il->status); ++ } else { ++ clear_bit(S_RFKILL, &il->status); + wiphy_rfkill_set_hw_state(il->hw->wiphy, hw_rf_kill); ++ il_force_reset(il, true); + } + + handled |= CSR_INT_BIT_RF_KILL; +--- a/drivers/net/wireless/iwlegacy/common.c ++++ b/drivers/net/wireless/iwlegacy/common.c +@@ -4660,6 +4660,7 @@ il_force_reset(struct il_priv *il, bool + + return 0; + } ++EXPORT_SYMBOL(il_force_reset); + + int + il_mac_change_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif, diff --git a/queue-3.10/iwl4965-set-power-mode-early.patch b/queue-3.10/iwl4965-set-power-mode-early.patch new file mode 100644 index 00000000000..378942b88cc --- /dev/null +++ b/queue-3.10/iwl4965-set-power-mode-early.patch @@ -0,0 +1,43 @@ +From eca396d7a5bdcc1fd67b1b12f737c213ac78a6f4 Mon Sep 17 00:00:00 2001 +From: Stanislaw Gruszka +Date: Thu, 1 Aug 2013 12:07:13 +0200 +Subject: iwl4965: set power mode early + +From: Stanislaw Gruszka + +commit eca396d7a5bdcc1fd67b1b12f737c213ac78a6f4 upstream. + +If device was put into a sleep and system was restarted or module +reloaded, we have to wake device up before sending other commands. +Otherwise it will fail to start with Microcode error. + +Signed-off-by: Stanislaw Gruszka +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/iwlegacy/4965-mac.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/net/wireless/iwlegacy/4965-mac.c ++++ b/drivers/net/wireless/iwlegacy/4965-mac.c +@@ -5316,6 +5316,9 @@ il4965_alive_start(struct il_priv *il) + + il->active_rate = RATES_MASK; + ++ il_power_update_mode(il, true); ++ D_INFO("Updated power mode\n"); ++ + if (il_is_associated(il)) { + struct il_rxon_cmd *active_rxon = + (struct il_rxon_cmd *)&il->active; +@@ -5346,9 +5349,6 @@ il4965_alive_start(struct il_priv *il) + D_INFO("ALIVE processing complete.\n"); + wake_up(&il->wait_command_queue); + +- il_power_update_mode(il, true); +- D_INFO("Updated power mode\n"); +- + return; + + restart: diff --git a/queue-3.10/mac80211-continue-using-disabled-channels-while-connected.patch b/queue-3.10/mac80211-continue-using-disabled-channels-while-connected.patch new file mode 100644 index 00000000000..390354a5b09 --- /dev/null +++ b/queue-3.10/mac80211-continue-using-disabled-channels-while-connected.patch @@ -0,0 +1,47 @@ +From ddfe49b42d8ad4bfdf92d63d4a74f162660d878d Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Wed, 31 Jul 2013 20:52:03 +0200 +Subject: mac80211: continue using disabled channels while connected + +From: Johannes Berg + +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 + +--- + net/mac80211/mlme.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +--- a/net/mac80211/mlme.c ++++ b/net/mac80211/mlme.c +@@ -361,8 +361,17 @@ out: + if (ret & IEEE80211_STA_DISABLE_VHT) + vht_chandef = *chandef; + ++ /* ++ * Ignore the DISABLED flag when we're already connected and only ++ * tracking the APs beacon for bandwidth changes - otherwise we ++ * might get disconnected here if we connect to an AP, update our ++ * regulatory information based on the AP's country IE and the ++ * information we have is wrong/outdated and disables the channel ++ * that we're actually using for the connection to the AP. ++ */ + while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef, +- IEEE80211_CHAN_DISABLED)) { ++ tracking ? 0 : ++ IEEE80211_CHAN_DISABLED)) { + if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) { + ret = IEEE80211_STA_DISABLE_HT | + IEEE80211_STA_DISABLE_VHT; diff --git a/queue-3.10/mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch b/queue-3.10/mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch new file mode 100644 index 00000000000..d71f524e5e7 --- /dev/null +++ b/queue-3.10/mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch @@ -0,0 +1,36 @@ +From b56e4b857c5210e848bfb80e074e5756a36cd523 Mon Sep 17 00:00:00 2001 +From: Chris Wright +Date: Wed, 31 Jul 2013 12:12:24 -0700 +Subject: mac80211: fix infinite loop in ieee80211_determine_chantype + +From: Chris Wright + +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 + +--- + net/mac80211/mlme.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/mac80211/mlme.c ++++ b/net/mac80211/mlme.c +@@ -366,7 +366,7 @@ out: + if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) { + ret = IEEE80211_STA_DISABLE_HT | + IEEE80211_STA_DISABLE_VHT; +- goto out; ++ break; + } + + ret |= chandef_downgrade(chandef); diff --git a/queue-3.10/mac80211-ignore-ht-primary-channel-while-connected.patch b/queue-3.10/mac80211-ignore-ht-primary-channel-while-connected.patch new file mode 100644 index 00000000000..0262cb32c93 --- /dev/null +++ b/queue-3.10/mac80211-ignore-ht-primary-channel-while-connected.patch @@ -0,0 +1,125 @@ +From 5cdaed1e878d723d56d04ae0be1738124acf9f46 Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Wed, 31 Jul 2013 11:23:06 +0200 +Subject: mac80211: ignore HT primary channel while connected + +From: Johannes Berg + +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 + +--- + net/mac80211/mlme.c | 26 +++++++++++++------------- + 1 file changed, 13 insertions(+), 13 deletions(-) + +--- a/net/mac80211/mlme.c ++++ b/net/mac80211/mlme.c +@@ -237,8 +237,9 @@ ieee80211_determine_chantype(struct ieee + struct ieee80211_channel *channel, + const struct ieee80211_ht_operation *ht_oper, + const struct ieee80211_vht_operation *vht_oper, +- struct cfg80211_chan_def *chandef, bool verbose) ++ struct cfg80211_chan_def *chandef, bool tracking) + { ++ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; + struct cfg80211_chan_def vht_chandef; + u32 ht_cfreq, ret; + +@@ -257,7 +258,7 @@ ieee80211_determine_chantype(struct ieee + ht_cfreq = ieee80211_channel_to_frequency(ht_oper->primary_chan, + channel->band); + /* check that channel matches the right operating channel */ +- if (channel->center_freq != ht_cfreq) { ++ if (!tracking && channel->center_freq != ht_cfreq) { + /* + * It's possible that some APs are confused here; + * Netgear WNDR3700 sometimes reports 4 higher than +@@ -265,11 +266,10 @@ ieee80211_determine_chantype(struct ieee + * since we look at probe response/beacon data here + * it should be OK. + */ +- if (verbose) +- sdata_info(sdata, +- "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n", +- channel->center_freq, ht_cfreq, +- ht_oper->primary_chan, channel->band); ++ sdata_info(sdata, ++ "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n", ++ channel->center_freq, ht_cfreq, ++ ht_oper->primary_chan, channel->band); + ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT; + goto out; + } +@@ -323,7 +323,7 @@ ieee80211_determine_chantype(struct ieee + channel->band); + break; + default: +- if (verbose) ++ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT)) + sdata_info(sdata, + "AP VHT operation IE has invalid channel width (%d), disable VHT\n", + vht_oper->chan_width); +@@ -332,7 +332,7 @@ ieee80211_determine_chantype(struct ieee + } + + if (!cfg80211_chandef_valid(&vht_chandef)) { +- if (verbose) ++ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT)) + sdata_info(sdata, + "AP VHT information is invalid, disable VHT\n"); + ret = IEEE80211_STA_DISABLE_VHT; +@@ -345,7 +345,7 @@ ieee80211_determine_chantype(struct ieee + } + + if (!cfg80211_chandef_compatible(chandef, &vht_chandef)) { +- if (verbose) ++ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT)) + sdata_info(sdata, + "AP VHT information doesn't match HT, disable VHT\n"); + ret = IEEE80211_STA_DISABLE_VHT; +@@ -372,7 +372,7 @@ out: + ret |= chandef_downgrade(chandef); + } + +- if (chandef->width != vht_chandef.width && verbose) ++ if (chandef->width != vht_chandef.width && !tracking) + sdata_info(sdata, + "capabilities/regulatory prevented using AP HT/VHT configuration, downgraded\n"); + +@@ -412,7 +412,7 @@ static int ieee80211_config_bw(struct ie + + /* calculate new channel (type) based on HT/VHT operation IEs */ + flags = ieee80211_determine_chantype(sdata, sband, chan, ht_oper, +- vht_oper, &chandef, false); ++ vht_oper, &chandef, true); + + /* + * Downgrade the new channel if we associated with restricted +@@ -3906,7 +3906,7 @@ static int ieee80211_prep_channel(struct + ifmgd->flags |= ieee80211_determine_chantype(sdata, sband, + cbss->channel, + ht_oper, vht_oper, +- &chandef, true); ++ &chandef, false); + + sdata->needed_rx_chains = min(ieee80211_ht_vht_rx_chains(sdata, cbss), + local->rx_chains); diff --git a/queue-3.10/series b/queue-3.10/series index 012da446e76..02891a15a80 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -9,3 +9,10 @@ elevator-fix-a-race-in-elevator-switching.patch arm-kvm-perform-save-restore-of-par.patch arm-kvm-add-missing-dsb-before-invalidating-stage-2-tlbs.patch arm-kvm-clear-exclusive-monitor-on-all-exception-returns.patch +iwl4965-set-power-mode-early.patch +iwl4965-reset-firmware-after-rfkill-off.patch +mac80211-ignore-ht-primary-channel-while-connected.patch +mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch +mac80211-continue-using-disabled-channels-while-connected.patch +can-pcan_usb-fix-wrong-memcpy-bytes-length.patch +genetlink-fix-family-dump-race.patch