--- /dev/null
+From 3c322a56b01695df15c70bfdc2d02e0ccd80654e Mon Sep 17 00:00:00 2001
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+Date: Fri, 9 Aug 2013 11:44:06 +0200
+Subject: can: pcan_usb: fix wrong memcpy() bytes length
+
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+
+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 <s.grosjean@peak-system.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
--- /dev/null
+From 58ad436fcf49810aa006016107f494c9ac9013db Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Tue, 13 Aug 2013 09:04:05 +0200
+Subject: genetlink: fix family dump race
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+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 <andrei.otcheretianski@intel.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
--- /dev/null
+From 788f7a56fce1bcb2067b62b851a086fca48a0056 Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+Date: Thu, 1 Aug 2013 12:07:55 +0200
+Subject: iwl4965: reset firmware after rfkill off
+
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+
+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 <whitefox@guardianfox.net>
+Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From eca396d7a5bdcc1fd67b1b12f737c213ac78a6f4 Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+Date: Thu, 1 Aug 2013 12:07:13 +0200
+Subject: iwl4965: set power mode early
+
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+
+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 <sgruszka@redhat.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From ddfe49b42d8ad4bfdf92d63d4a74f162660d878d Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Wed, 31 Jul 2013 20:52:03 +0200
+Subject: mac80211: continue using disabled channels while connected
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+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 <chrisw@sous-sol.org>
+Tested-by: Chris Wright <chrisw@sous-sol.org>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From b56e4b857c5210e848bfb80e074e5756a36cd523 Mon Sep 17 00:00:00 2001
+From: Chris Wright <chrisw@sous-sol.org>
+Date: Wed, 31 Jul 2013 12:12:24 -0700
+Subject: mac80211: fix infinite loop in ieee80211_determine_chantype
+
+From: Chris Wright <chrisw@sous-sol.org>
+
+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 <chrisw@sous-sol.org>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 5cdaed1e878d723d56d04ae0be1738124acf9f46 Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Wed, 31 Jul 2013 11:23:06 +0200
+Subject: mac80211: ignore HT primary channel while connected
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+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 <adi@hexapodia.org>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
