iwl7000: Pick up bug-fixes from Intel, week of 2/17 |
|||||||||||||||||||||||
Issue descriptionUsing this as a tracking bug to pick up bug-fixes for iwl7000. For full list of patches (7 patches * 5 kernel versions), check `gerrit search 'owner:Luca Coelho AND status:open` in cros_sdk.
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1dadc871060c8be4d359dc30f613ab36b86c958b commit 1dadc871060c8be4d359dc30f613ab36b86c958b Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 09:47:24 2017 CHROMIUM: iwl7000: mac80211: initialize fast-xmit 'info' later In ieee80211_xmit_fast(), 'info' is initialized to point to the skb that's passed in, but that skb may later be replaced by a clone (if it was shared), leading to an invalid pointer. This can lead to use-after-free and also later crashes since the real SKB's info->hw_queue doesn't get initialized properly. Fix this by assigning info only later, when it's needed, after the skb replacement (may have) happened. (that's not really the broken commit, but rather the one that enabled the broken code for our driver) Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 0509d2fc9c0149cb21668d45fff567eb524a49b4) iwl7000-tree: 7726f6a41e33303a32a016358e8e3bd5daa5cb25 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I6d50aeb403d1a1ce57bc8efcdacd4936e951bd0f Reviewed-on: https://chromium-review.googlesource.com/442507 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/1dadc871060c8be4d359dc30f613ab36b86c958b/drivers/net/wireless/iwl7000/mac80211/tx.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/38817da1592ca112211029d11cae2d016bb78577 commit 38817da1592ca112211029d11cae2d016bb78577 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 09:47:23 2017 CHROMIUM: iwl7000: mac80211: discard multicast and 4-addr A-MSDUs In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in: * drop A-MSDUs with a multicast A1 (RA), as required by the spec in 9.11 (802.11-2012 version) * drop A-MSDUs with a 4-addr header, since the fourth address can't actually be useful for them; unless 4-address frame format is actually requested, even though the fourth address is still not useful in this case, but ignored Accepting the first case, in particular, is very problematic since it allows anyone else with possession of a GTK to send unicast frames encapsulated in a multicast A-MSDU, even when the AP has client isolation enabled. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit b5d460db1fee755bda9240b7c3b4bd7c7a89646d) iwl7000-tree: 905f3c665a56b56d8d79cbd308ce30768d4a6f34 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I651ba6c427478e351d1671910180e1cb6ff46217 Reviewed-on: https://chromium-review.googlesource.com/442506 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/38817da1592ca112211029d11cae2d016bb78577/drivers/net/wireless/iwl7000/mac80211/rx.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c4e5760533ab4447af1421999e89a73575bc5183 commit c4e5760533ab4447af1421999e89a73575bc5183 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri Feb 17 09:47:25 2017 CHROMIUM: iwl7000: pcie: don't increment / decrement a bool David reported that the code I added uses the decrement and increment operator on a boolean variable. Fix that. Fixes: 0cd58eaab148 ("iwlwifi: pcie: allow the op_mode to block the tx queues") CC: stable@vger.kernel.org [4.5+] Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> (cherry picked from commit f56ea9b41265a1395704284042c3c14a2bc37d3c) iwl7000-tree: 17857a0660fbd59f3de31645ffadeb7d32d93c3f Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I97495518e3c4f5b2d64cc2da96615f965f9e7e65 Reviewed-on: https://chromium-review.googlesource.com/442508 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/c4e5760533ab4447af1421999e89a73575bc5183/drivers/net/wireless/iwl7000/iwlwifi/pcie/internal.h
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/af52bea7457203c3f234610e8f6d8c546588b5b9 commit af52bea7457203c3f234610e8f6d8c546588b5b9 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 09:47:26 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory (de)registration Since callers can assume, due to the way this works in the normal cfg80211, that the wiphy pointer is valid even when the device has been or is being unregistered, defer the intel regulatory deregistration until free. To make error cases work correctly, also do the registration at alloc. Also squashed with: "CHROMIUM: iwl7000: chromeOS: register Intel regulatory in register_hw() This partially reverts my previous change: moving the regulatory registration into alloc_hw() is broken since then by that point the REGULATORY_WIPHY_SELF_MANAGED flag can't have been set yet, and thus registration will be ignored. I originally moved the register to be symmetric with unregister (which moved to free), but since unregister is idempotent and doesn't care if you unregister something that was never actually registered, it's safe to register only in register_hw() and yet unregister in free_hw()." BUG= chromium:693295 TEST=None Change-Id: Ie56f713dbcc18888d72d7e158178ee1133aeb81a Signed-off-by: Johannes Berg <johannes.berg@intel.com> iwl7000-tree: e1fe68f6b717e5b376addae692345f7ccd44ecf0 iwl7000-tree: 2daba21d5948d9205a92f69ad6a9768df760e211 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/442509 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/af52bea7457203c3f234610e8f6d8c546588b5b9/drivers/net/wireless/iwl7000/mac80211/main.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1a63e4dd93bf0a0599e10766ceb0cbfdc03b4fbd commit 1a63e4dd93bf0a0599e10766ceb0cbfdc03b4fbd Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 09:47:27 2017 CHROMIUM: iwl7000: chromeOS: regulatory: fix various locking issues Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 250247ebe0f66847cdd79570e1bbdcd4e684515b) iwl7000-tree: 48abb032b882be29bde1af74f3d8d556415f43bf Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Ib0c8ad232340091ea4ce5c52a1fbfb86550773f4 Reviewed-on: https://chromium-review.googlesource.com/442510 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/1a63e4dd93bf0a0599e10766ceb0cbfdc03b4fbd/drivers/net/wireless/iwl7000/mac80211/reg.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7efccdd303b3c7efa107542a69756f28c2d6191f commit 7efccdd303b3c7efa107542a69756f28c2d6191f Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 09:47:27 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory locking Not all places access the list with the RTNL held, so also use the reg_requests_lock, which we already need, to protect against list corruption. BUG= chromium:693295 TEST=None Change-Id: Ib6614135b15d7106e1a5ba415d049768a6ae9428 Signed-off-by: Johannes Berg <johannes.berg@intel.com> iwl7000-tree: a65e96963c89f3b331e1ffa6ab5bcdfa2ddb886a Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/442511 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/7efccdd303b3c7efa107542a69756f28c2d6191f/drivers/net/wireless/iwl7000/mac80211/reg.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/483ac334d4113dde815e83f556731d3cff0740db commit 483ac334d4113dde815e83f556731d3cff0740db Author: Matt Chen <matt.chen@intel.com> Date: Fri Feb 17 09:47:28 2017 CHROMIUM: iwl7000: mac80211: flush delayed work when enter suspend The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen <matt.chen@intel.com> (cherry picked from commit 835ed86aebb0b38738f097290a159ccc10583f5a) iwl7000-tree: 7bac424534a8e132f1c5257c2b770409059d6009 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I3b0d753c0171de16804f90523f44251bd43b82a0 Reviewed-on: https://chromium-review.googlesource.com/442512 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/483ac334d4113dde815e83f556731d3cff0740db/drivers/net/wireless/iwl7000/mac80211/pm.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6e2386908b18e822769443f56ac750d4ac34bea5 commit 6e2386908b18e822769443f56ac750d4ac34bea5 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 12:09:24 2017 CHROMIUM: iwl7000: mac80211: discard multicast and 4-addr A-MSDUs In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in: * drop A-MSDUs with a multicast A1 (RA), as required by the spec in 9.11 (802.11-2012 version) * drop A-MSDUs with a 4-addr header, since the fourth address can't actually be useful for them; unless 4-address frame format is actually requested, even though the fourth address is still not useful in this case, but ignored Accepting the first case, in particular, is very problematic since it allows anyone else with possession of a GTK to send unicast frames encapsulated in a multicast A-MSDU, even when the AP has client isolation enabled. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit b5d460db1fee755bda9240b7c3b4bd7c7a89646d) iwl7000-tree: 905f3c665a56b56d8d79cbd308ce30768d4a6f34 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Iaefc9a42ab92755c2e4dad60fbfa7cfdf30a5b70 Reviewed-on: https://chromium-review.googlesource.com/442546 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/6e2386908b18e822769443f56ac750d4ac34bea5/drivers/net/wireless/iwl7000/mac80211/rx.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1e4d143f06d529219663db3635140414fbaf1286 commit 1e4d143f06d529219663db3635140414fbaf1286 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 12:09:25 2017 CHROMIUM: iwl7000: mac80211: initialize fast-xmit 'info' later In ieee80211_xmit_fast(), 'info' is initialized to point to the skb that's passed in, but that skb may later be replaced by a clone (if it was shared), leading to an invalid pointer. This can lead to use-after-free and also later crashes since the real SKB's info->hw_queue doesn't get initialized properly. Fix this by assigning info only later, when it's needed, after the skb replacement (may have) happened. (that's not really the broken commit, but rather the one that enabled the broken code for our driver) Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 0509d2fc9c0149cb21668d45fff567eb524a49b4) iwl7000-tree: 7726f6a41e33303a32a016358e8e3bd5daa5cb25 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I056d5921af1f4e1933502619a0b007454730352d Reviewed-on: https://chromium-review.googlesource.com/442547 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/1e4d143f06d529219663db3635140414fbaf1286/drivers/net/wireless/iwl7000/mac80211/tx.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2885db36e751245036e2cc67e3d01cd734a68c38 commit 2885db36e751245036e2cc67e3d01cd734a68c38 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri Feb 17 12:09:26 2017 CHROMIUM: iwl7000: pcie: don't increment / decrement a bool David reported that the code I added uses the decrement and increment operator on a boolean variable. Fix that. Fixes: 0cd58eaab148 ("iwlwifi: pcie: allow the op_mode to block the tx queues") CC: stable@vger.kernel.org [4.5+] Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> (cherry picked from commit f56ea9b41265a1395704284042c3c14a2bc37d3c) iwl7000-tree: 17857a0660fbd59f3de31645ffadeb7d32d93c3f Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Icc20db81388a153243dd49657169a307f0708d51 Reviewed-on: https://chromium-review.googlesource.com/442548 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/2885db36e751245036e2cc67e3d01cd734a68c38/drivers/net/wireless/iwl7000/iwlwifi/pcie/internal.h
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/02225708e7e57f8c971fc94b370a7ea273af6e25 commit 02225708e7e57f8c971fc94b370a7ea273af6e25 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 12:09:27 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory (de)registration Since callers can assume, due to the way this works in the normal cfg80211, that the wiphy pointer is valid even when the device has been or is being unregistered, defer the intel regulatory deregistration until free. To make error cases work correctly, also do the registration at alloc. Also squashed with: "CHROMIUM: iwl7000: chromeOS: register Intel regulatory in register_hw() This partially reverts my previous change: moving the regulatory registration into alloc_hw() is broken since then by that point the REGULATORY_WIPHY_SELF_MANAGED flag can't have been set yet, and thus registration will be ignored. I originally moved the register to be symmetric with unregister (which moved to free), but since unregister is idempotent and doesn't care if you unregister something that was never actually registered, it's safe to register only in register_hw() and yet unregister in free_hw()." BUG= chromium:693295 TEST=None Change-Id: If1b8d5a0b38ea8d6ab56aeaf4711a019fa881ad5 Signed-off-by: Johannes Berg <johannes.berg@intel.com> iwl7000-tree: e1fe68f6b717e5b376addae692345f7ccd44ecf0 iwl7000-tree: 2daba21d5948d9205a92f69ad6a9768df760e211 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/442549 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/02225708e7e57f8c971fc94b370a7ea273af6e25/drivers/net/wireless/iwl7000/mac80211/main.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d7c3e18b2be22688ecf28ed4dd4a0f14d0197698 commit d7c3e18b2be22688ecf28ed4dd4a0f14d0197698 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 12:09:28 2017 CHROMIUM: iwl7000: chromeOS: regulatory: fix various locking issues Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 250247ebe0f66847cdd79570e1bbdcd4e684515b) iwl7000-tree: 48abb032b882be29bde1af74f3d8d556415f43bf Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Ie4fef34a4699bb0105cf6d1573ab3f243d84da12 Reviewed-on: https://chromium-review.googlesource.com/442550 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/d7c3e18b2be22688ecf28ed4dd4a0f14d0197698/drivers/net/wireless/iwl7000/mac80211/reg.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d38d9b97ec1ac31d0ed388b7f630083bdbfec60d commit d38d9b97ec1ac31d0ed388b7f630083bdbfec60d Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 12:09:29 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory locking Not all places access the list with the RTNL held, so also use the reg_requests_lock, which we already need, to protect against list corruption. BUG= chromium:693295 TEST=None Change-Id: I842a14802b93ba2162a08cfd3d4422d3907d5be0 Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: a65e96963c89f3b331e1ffa6ab5bcdfa2ddb886a Reviewed-on: https://chromium-review.googlesource.com/442551 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/d38d9b97ec1ac31d0ed388b7f630083bdbfec60d/drivers/net/wireless/iwl7000/mac80211/reg.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4405848f3d5f146f61485cbb6dad3c5efdd71817 commit 4405848f3d5f146f61485cbb6dad3c5efdd71817 Author: Matt Chen <matt.chen@intel.com> Date: Fri Feb 17 12:09:30 2017 CHROMIUM: iwl7000: mac80211: flush delayed work when enter suspend The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen <matt.chen@intel.com> (cherry picked from commit 835ed86aebb0b38738f097290a159ccc10583f5a) iwl7000-tree: 7bac424534a8e132f1c5257c2b770409059d6009 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I2f5e32c7fe7b9ddc3c6e91680abc001ecc9526d7 Reviewed-on: https://chromium-review.googlesource.com/442552 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/4405848f3d5f146f61485cbb6dad3c5efdd71817/drivers/net/wireless/iwl7000/mac80211/pm.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ad3322eae3b593c11d404d55fd47d8c2c80836a7 commit ad3322eae3b593c11d404d55fd47d8c2c80836a7 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 12:09:31 2017 CHROMIUM: iwl7000: mac80211: initialize fast-xmit 'info' later In ieee80211_xmit_fast(), 'info' is initialized to point to the skb that's passed in, but that skb may later be replaced by a clone (if it was shared), leading to an invalid pointer. This can lead to use-after-free and also later crashes since the real SKB's info->hw_queue doesn't get initialized properly. Fix this by assigning info only later, when it's needed, after the skb replacement (may have) happened. (that's not really the broken commit, but rather the one that enabled the broken code for our driver) Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 0509d2fc9c0149cb21668d45fff567eb524a49b4) iwl7000-tree: 7726f6a41e33303a32a016358e8e3bd5daa5cb25 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I056d5921af1f4e1933502619a0b007454730352d Reviewed-on: https://chromium-review.googlesource.com/442605 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/ad3322eae3b593c11d404d55fd47d8c2c80836a7/drivers/net/wireless-3.8/iwl7000/mac80211/tx.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8aeaba8e9f1a0af0c5c6a9a261541385f4fe6568 commit 8aeaba8e9f1a0af0c5c6a9a261541385f4fe6568 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri Feb 17 12:09:32 2017 CHROMIUM: iwl7000: pcie: don't increment / decrement a bool David reported that the code I added uses the decrement and increment operator on a boolean variable. Fix that. Fixes: 0cd58eaab148 ("iwlwifi: pcie: allow the op_mode to block the tx queues") CC: stable@vger.kernel.org [4.5+] Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> (cherry picked from commit f56ea9b41265a1395704284042c3c14a2bc37d3c) iwl7000-tree: 17857a0660fbd59f3de31645ffadeb7d32d93c3f Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Icc20db81388a153243dd49657169a307f0708d51 Reviewed-on: https://chromium-review.googlesource.com/442606 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/8aeaba8e9f1a0af0c5c6a9a261541385f4fe6568/drivers/net/wireless-3.8/iwl7000/iwlwifi/pcie/internal.h
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ef4b5b873d8073be6c5d274846501b4fa1d8e316 commit ef4b5b873d8073be6c5d274846501b4fa1d8e316 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 12:09:33 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory (de)registration Since callers can assume, due to the way this works in the normal cfg80211, that the wiphy pointer is valid even when the device has been or is being unregistered, defer the intel regulatory deregistration until free. To make error cases work correctly, also do the registration at alloc. Also squashed with: "CHROMIUM: iwl7000: chromeOS: register Intel regulatory in register_hw() This partially reverts my previous change: moving the regulatory registration into alloc_hw() is broken since then by that point the REGULATORY_WIPHY_SELF_MANAGED flag can't have been set yet, and thus registration will be ignored. I originally moved the register to be symmetric with unregister (which moved to free), but since unregister is idempotent and doesn't care if you unregister something that was never actually registered, it's safe to register only in register_hw() and yet unregister in free_hw()." BUG= chromium:693295 TEST=None Change-Id: If1b8d5a0b38ea8d6ab56aeaf4711a019fa881ad5 Signed-off-by: Johannes Berg <johannes.berg@intel.com> iwl7000-tree: e1fe68f6b717e5b376addae692345f7ccd44ecf0 iwl7000-tree: 2daba21d5948d9205a92f69ad6a9768df760e211 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/442607 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/ef4b5b873d8073be6c5d274846501b4fa1d8e316/drivers/net/wireless-3.8/iwl7000/mac80211/main.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ac1a440bea1256e98fea259019df85323de56e29 commit ac1a440bea1256e98fea259019df85323de56e29 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 12:09:34 2017 CHROMIUM: iwl7000: chromeOS: regulatory: fix various locking issues Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 250247ebe0f66847cdd79570e1bbdcd4e684515b) iwl7000-tree: 48abb032b882be29bde1af74f3d8d556415f43bf Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Ie4fef34a4699bb0105cf6d1573ab3f243d84da12 Reviewed-on: https://chromium-review.googlesource.com/442608 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/ac1a440bea1256e98fea259019df85323de56e29/drivers/net/wireless-3.8/iwl7000/mac80211/reg.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/32959fcedca53a183d9d818e4ee4b2bfc39628bf commit 32959fcedca53a183d9d818e4ee4b2bfc39628bf Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Feb 17 12:09:35 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory locking Not all places access the list with the RTNL held, so also use the reg_requests_lock, which we already need, to protect against list corruption. BUG= chromium:693295 TEST=None Change-Id: I842a14802b93ba2162a08cfd3d4422d3907d5be0 Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: a65e96963c89f3b331e1ffa6ab5bcdfa2ddb886a Reviewed-on: https://chromium-review.googlesource.com/442609 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/32959fcedca53a183d9d818e4ee4b2bfc39628bf/drivers/net/wireless-3.8/iwl7000/mac80211/reg.c
,
Feb 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a95b445f3149765e80bc63c270e0f424afc3e2c3 commit a95b445f3149765e80bc63c270e0f424afc3e2c3 Author: Matt Chen <matt.chen@intel.com> Date: Fri Feb 17 12:09:36 2017 CHROMIUM: iwl7000: mac80211: flush delayed work when enter suspend The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen <matt.chen@intel.com> (cherry picked from commit 835ed86aebb0b38738f097290a159ccc10583f5a) iwl7000-tree: 7bac424534a8e132f1c5257c2b770409059d6009 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I2f5e32c7fe7b9ddc3c6e91680abc001ecc9526d7 Reviewed-on: https://chromium-review.googlesource.com/442610 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/a95b445f3149765e80bc63c270e0f424afc3e2c3/drivers/net/wireless-3.8/iwl7000/mac80211/pm.c
,
Feb 19 2017
Hi ketakid@, Intel has begun a routine of giving us "stable fixes" once a week. This is the first among them. This bug tracks 7 patches (* 5 kernels) intended for ToT, of which I am requesting the following 3 patches per kernel to be merged into M57 (the other 4 need bake-time on canary): 1. https://chromium-review.googlesource.com/#/c/442507/ 2. https://chromium-review.googlesource.com/#/c/442508/ 3. https://chromium-review.googlesource.com/#/c/442512/ This fixes the kernel warning in https://code.google.com/p/chrome-os-partner/issues/detail?id=62285
,
Feb 20 2017
Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions. Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 23 2017
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 27 2017
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1bebbe4cee84353edf460a26ff2433b9a8d44e94 commit 1bebbe4cee84353edf460a26ff2433b9a8d44e94 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 04:17:28 2017 CHROMIUM: iwl7000: mac80211: discard multicast and 4-addr A-MSDUs In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in: * drop A-MSDUs with a multicast A1 (RA), as required by the spec in 9.11 (802.11-2012 version) * drop A-MSDUs with a 4-addr header, since the fourth address can't actually be useful for them; unless 4-address frame format is actually requested, even though the fourth address is still not useful in this case, but ignored Accepting the first case, in particular, is very problematic since it allows anyone else with possession of a GTK to send unicast frames encapsulated in a multicast A-MSDU, even when the AP has client isolation enabled. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit b5d460db1fee755bda9240b7c3b4bd7c7a89646d) iwl7000-tree: 905f3c665a56b56d8d79cbd308ce30768d4a6f34 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Iaefc9a42ab92755c2e4dad60fbfa7cfdf30a5b70 Reviewed-on: https://chromium-review.googlesource.com/442611 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/1bebbe4cee84353edf460a26ff2433b9a8d44e94/drivers/net/wireless/iwl7000/mac80211/rx.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ce32ca74c86648447439ef564dee883bce23566b commit ce32ca74c86648447439ef564dee883bce23566b Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 04:17:29 2017 CHROMIUM: iwl7000: mac80211: initialize fast-xmit 'info' later In ieee80211_xmit_fast(), 'info' is initialized to point to the skb that's passed in, but that skb may later be replaced by a clone (if it was shared), leading to an invalid pointer. This can lead to use-after-free and also later crashes since the real SKB's info->hw_queue doesn't get initialized properly. Fix this by assigning info only later, when it's needed, after the skb replacement (may have) happened. (that's not really the broken commit, but rather the one that enabled the broken code for our driver) Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 0509d2fc9c0149cb21668d45fff567eb524a49b4) iwl7000-tree: 7726f6a41e33303a32a016358e8e3bd5daa5cb25 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I056d5921af1f4e1933502619a0b007454730352d Reviewed-on: https://chromium-review.googlesource.com/442612 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/ce32ca74c86648447439ef564dee883bce23566b/drivers/net/wireless/iwl7000/mac80211/tx.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b4803ed63478aa96c0a20c99927141cc31091bd2 commit b4803ed63478aa96c0a20c99927141cc31091bd2 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 04:17:31 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory (de)registration Since callers can assume, due to the way this works in the normal cfg80211, that the wiphy pointer is valid even when the device has been or is being unregistered, defer the intel regulatory deregistration until free. To make error cases work correctly, also do the registration at alloc. Also squashed with: "CHROMIUM: iwl7000: chromeOS: register Intel regulatory in register_hw() This partially reverts my previous change: moving the regulatory registration into alloc_hw() is broken since then by that point the REGULATORY_WIPHY_SELF_MANAGED flag can't have been set yet, and thus registration will be ignored. I originally moved the register to be symmetric with unregister (which moved to free), but since unregister is idempotent and doesn't care if you unregister something that was never actually registered, it's safe to register only in register_hw() and yet unregister in free_hw()." BUG= chromium:693295 TEST=None Change-Id: If1b8d5a0b38ea8d6ab56aeaf4711a019fa881ad5 Signed-off-by: Johannes Berg <johannes.berg@intel.com> iwl7000-tree: e1fe68f6b717e5b376addae692345f7ccd44ecf0 iwl7000-tree: 2daba21d5948d9205a92f69ad6a9768df760e211 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/442614 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/b4803ed63478aa96c0a20c99927141cc31091bd2/drivers/net/wireless/iwl7000/mac80211/main.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c84cf304dba77f2d8256ebded0cbbdca245fcb7f commit c84cf304dba77f2d8256ebded0cbbdca245fcb7f Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri Mar 03 04:17:30 2017 CHROMIUM: iwl7000: pcie: don't increment / decrement a bool David reported that the code I added uses the decrement and increment operator on a boolean variable. Fix that. Fixes: 0cd58eaab148 ("iwlwifi: pcie: allow the op_mode to block the tx queues") CC: stable@vger.kernel.org [4.5+] Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> (cherry picked from commit f56ea9b41265a1395704284042c3c14a2bc37d3c) iwl7000-tree: 17857a0660fbd59f3de31645ffadeb7d32d93c3f Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Icc20db81388a153243dd49657169a307f0708d51 Reviewed-on: https://chromium-review.googlesource.com/442613 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/c84cf304dba77f2d8256ebded0cbbdca245fcb7f/drivers/net/wireless/iwl7000/iwlwifi/pcie/internal.h
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0263e120fe0cda2b68faf042991b32bdf349e30c commit 0263e120fe0cda2b68faf042991b32bdf349e30c Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 04:17:33 2017 CHROMIUM: iwl7000: chromeOS: regulatory: fix various locking issues Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 250247ebe0f66847cdd79570e1bbdcd4e684515b) iwl7000-tree: 48abb032b882be29bde1af74f3d8d556415f43bf Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Ie4fef34a4699bb0105cf6d1573ab3f243d84da12 Reviewed-on: https://chromium-review.googlesource.com/442615 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/0263e120fe0cda2b68faf042991b32bdf349e30c/drivers/net/wireless/iwl7000/mac80211/reg.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6e6b4010d737ad8a38e240b2d5dda9fdd80df23d commit 6e6b4010d737ad8a38e240b2d5dda9fdd80df23d Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 04:17:34 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory locking Not all places access the list with the RTNL held, so also use the reg_requests_lock, which we already need, to protect against list corruption. BUG= chromium:693295 TEST=None Change-Id: I842a14802b93ba2162a08cfd3d4422d3907d5be0 Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: a65e96963c89f3b331e1ffa6ab5bcdfa2ddb886a Reviewed-on: https://chromium-review.googlesource.com/442616 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/6e6b4010d737ad8a38e240b2d5dda9fdd80df23d/drivers/net/wireless/iwl7000/mac80211/reg.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/026dfb4ef627a7014bcfe73865a0507253be5205 commit 026dfb4ef627a7014bcfe73865a0507253be5205 Author: Matt Chen <matt.chen@intel.com> Date: Fri Mar 03 04:17:35 2017 CHROMIUM: iwl7000: mac80211: flush delayed work when enter suspend The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen <matt.chen@intel.com> (cherry picked from commit 835ed86aebb0b38738f097290a159ccc10583f5a) iwl7000-tree: 7bac424534a8e132f1c5257c2b770409059d6009 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I2f5e32c7fe7b9ddc3c6e91680abc001ecc9526d7 Reviewed-on: https://chromium-review.googlesource.com/442617 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/026dfb4ef627a7014bcfe73865a0507253be5205/drivers/net/wireless/iwl7000/mac80211/pm.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6cfb11596ef8608a6f48b2f0ba86724bf7efabf9 commit 6cfb11596ef8608a6f48b2f0ba86724bf7efabf9 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 04:17:37 2017 CHROMIUM: iwl7000: mac80211: initialize fast-xmit 'info' later In ieee80211_xmit_fast(), 'info' is initialized to point to the skb that's passed in, but that skb may later be replaced by a clone (if it was shared), leading to an invalid pointer. This can lead to use-after-free and also later crashes since the real SKB's info->hw_queue doesn't get initialized properly. Fix this by assigning info only later, when it's needed, after the skb replacement (may have) happened. (that's not really the broken commit, but rather the one that enabled the broken code for our driver) Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 0509d2fc9c0149cb21668d45fff567eb524a49b4) iwl7000-tree: 7726f6a41e33303a32a016358e8e3bd5daa5cb25 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I056d5921af1f4e1933502619a0b007454730352d Reviewed-on: https://chromium-review.googlesource.com/442554 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/6cfb11596ef8608a6f48b2f0ba86724bf7efabf9/drivers/net/wireless-3.8/iwl7000/mac80211/tx.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2db263af31c775754d36a14f0305abc4ad2c2e05 commit 2db263af31c775754d36a14f0305abc4ad2c2e05 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 04:17:36 2017 CHROMIUM: iwl7000: mac80211: discard multicast and 4-addr A-MSDUs In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in: * drop A-MSDUs with a multicast A1 (RA), as required by the spec in 9.11 (802.11-2012 version) * drop A-MSDUs with a 4-addr header, since the fourth address can't actually be useful for them; unless 4-address frame format is actually requested, even though the fourth address is still not useful in this case, but ignored Accepting the first case, in particular, is very problematic since it allows anyone else with possession of a GTK to send unicast frames encapsulated in a multicast A-MSDU, even when the AP has client isolation enabled. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit b5d460db1fee755bda9240b7c3b4bd7c7a89646d) iwl7000-tree: 905f3c665a56b56d8d79cbd308ce30768d4a6f34 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Iaefc9a42ab92755c2e4dad60fbfa7cfdf30a5b70 Reviewed-on: https://chromium-review.googlesource.com/442553 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/2db263af31c775754d36a14f0305abc4ad2c2e05/drivers/net/wireless-3.8/iwl7000/mac80211/rx.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/50e785a9b4b6a265f71842eefe6c78da1b623ddc commit 50e785a9b4b6a265f71842eefe6c78da1b623ddc Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri Mar 03 04:17:38 2017 CHROMIUM: iwl7000: pcie: don't increment / decrement a bool David reported that the code I added uses the decrement and increment operator on a boolean variable. Fix that. Fixes: 0cd58eaab148 ("iwlwifi: pcie: allow the op_mode to block the tx queues") CC: stable@vger.kernel.org [4.5+] Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> (cherry picked from commit f56ea9b41265a1395704284042c3c14a2bc37d3c) iwl7000-tree: 17857a0660fbd59f3de31645ffadeb7d32d93c3f Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Icc20db81388a153243dd49657169a307f0708d51 Reviewed-on: https://chromium-review.googlesource.com/442555 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/50e785a9b4b6a265f71842eefe6c78da1b623ddc/drivers/net/wireless-3.8/iwl7000/iwlwifi/pcie/internal.h
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/93200b4abee165423b0bf345cbf5fe19a0ed5f4f commit 93200b4abee165423b0bf345cbf5fe19a0ed5f4f Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 04:17:39 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory (de)registration Since callers can assume, due to the way this works in the normal cfg80211, that the wiphy pointer is valid even when the device has been or is being unregistered, defer the intel regulatory deregistration until free. To make error cases work correctly, also do the registration at alloc. Also squashed with: "CHROMIUM: iwl7000: chromeOS: register Intel regulatory in register_hw() This partially reverts my previous change: moving the regulatory registration into alloc_hw() is broken since then by that point the REGULATORY_WIPHY_SELF_MANAGED flag can't have been set yet, and thus registration will be ignored. I originally moved the register to be symmetric with unregister (which moved to free), but since unregister is idempotent and doesn't care if you unregister something that was never actually registered, it's safe to register only in register_hw() and yet unregister in free_hw()." BUG= chromium:693295 TEST=None Change-Id: If1b8d5a0b38ea8d6ab56aeaf4711a019fa881ad5 Signed-off-by: Johannes Berg <johannes.berg@intel.com> iwl7000-tree: e1fe68f6b717e5b376addae692345f7ccd44ecf0 iwl7000-tree: 2daba21d5948d9205a92f69ad6a9768df760e211 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/442556 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/93200b4abee165423b0bf345cbf5fe19a0ed5f4f/drivers/net/wireless-3.8/iwl7000/mac80211/main.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6497e4e7eefa2e08edb435f9d622ce7389218288 commit 6497e4e7eefa2e08edb435f9d622ce7389218288 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 04:17:41 2017 CHROMIUM: iwl7000: chromeOS: regulatory: fix various locking issues Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 250247ebe0f66847cdd79570e1bbdcd4e684515b) iwl7000-tree: 48abb032b882be29bde1af74f3d8d556415f43bf Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: Ie4fef34a4699bb0105cf6d1573ab3f243d84da12 Reviewed-on: https://chromium-review.googlesource.com/442557 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/6497e4e7eefa2e08edb435f9d622ce7389218288/drivers/net/wireless-3.8/iwl7000/mac80211/reg.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/457156b7fafdc529f6b0cb22944e75386674204e commit 457156b7fafdc529f6b0cb22944e75386674204e Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 04:17:42 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory locking Not all places access the list with the RTNL held, so also use the reg_requests_lock, which we already need, to protect against list corruption. BUG= chromium:693295 TEST=None Change-Id: I842a14802b93ba2162a08cfd3d4422d3907d5be0 Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: a65e96963c89f3b331e1ffa6ab5bcdfa2ddb886a Reviewed-on: https://chromium-review.googlesource.com/442558 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/457156b7fafdc529f6b0cb22944e75386674204e/drivers/net/wireless-3.8/iwl7000/mac80211/reg.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/302842a8d60dcc8b3c2420459928aa048bb3ae72 commit 302842a8d60dcc8b3c2420459928aa048bb3ae72 Author: Matt Chen <matt.chen@intel.com> Date: Fri Mar 03 04:17:43 2017 CHROMIUM: iwl7000: mac80211: flush delayed work when enter suspend The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen <matt.chen@intel.com> (cherry picked from commit 835ed86aebb0b38738f097290a159ccc10583f5a) iwl7000-tree: 7bac424534a8e132f1c5257c2b770409059d6009 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I2f5e32c7fe7b9ddc3c6e91680abc001ecc9526d7 Reviewed-on: https://chromium-review.googlesource.com/442559 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/302842a8d60dcc8b3c2420459928aa048bb3ae72/drivers/net/wireless-3.8/iwl7000/mac80211/pm.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/08fbd9cee96c54804762a64fa031812d6324a56b commit 08fbd9cee96c54804762a64fa031812d6324a56b Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 19:59:23 2017 CHROMIUM: iwl7000: mac80211: initialize fast-xmit 'info' later In ieee80211_xmit_fast(), 'info' is initialized to point to the skb that's passed in, but that skb may later be replaced by a clone (if it was shared), leading to an invalid pointer. This can lead to use-after-free and also later crashes since the real SKB's info->hw_queue doesn't get initialized properly. Fix this by assigning info only later, when it's needed, after the skb replacement (may have) happened. (that's not really the broken commit, but rather the one that enabled the broken code for our driver) Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 0509d2fc9c0149cb21668d45fff567eb524a49b4) iwl7000-tree: 7726f6a41e33303a32a016358e8e3bd5daa5cb25 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I056d5921af1f4e1933502619a0b007454730352d Reviewed-on: https://chromium-review.googlesource.com/442554 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 6cfb11596ef8608a6f48b2f0ba86724bf7efabf9) Reviewed-on: https://chromium-review.googlesource.com/449029 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/08fbd9cee96c54804762a64fa031812d6324a56b/drivers/net/wireless-3.8/iwl7000/mac80211/tx.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/69eb7cf90e74270b17a4de944e1b62627ac97686 commit 69eb7cf90e74270b17a4de944e1b62627ac97686 Author: Matt Chen <matt.chen@intel.com> Date: Fri Mar 03 19:59:19 2017 CHROMIUM: iwl7000: mac80211: flush delayed work when enter suspend The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen <matt.chen@intel.com> (cherry picked from commit 835ed86aebb0b38738f097290a159ccc10583f5a) iwl7000-tree: 7bac424534a8e132f1c5257c2b770409059d6009 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I2f5e32c7fe7b9ddc3c6e91680abc001ecc9526d7 Reviewed-on: https://chromium-review.googlesource.com/442559 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 302842a8d60dcc8b3c2420459928aa048bb3ae72) Reviewed-on: https://chromium-review.googlesource.com/449028 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/69eb7cf90e74270b17a4de944e1b62627ac97686/drivers/net/wireless-3.8/iwl7000/mac80211/pm.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b04685b795e4187fe840f1dd73700d0e417d7b54 commit b04685b795e4187fe840f1dd73700d0e417d7b54 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 03 20:34:34 2017 CHROMIUM: iwl7000: mac80211: initialize fast-xmit 'info' later In ieee80211_xmit_fast(), 'info' is initialized to point to the skb that's passed in, but that skb may later be replaced by a clone (if it was shared), leading to an invalid pointer. This can lead to use-after-free and also later crashes since the real SKB's info->hw_queue doesn't get initialized properly. Fix this by assigning info only later, when it's needed, after the skb replacement (may have) happened. (that's not really the broken commit, but rather the one that enabled the broken code for our driver) Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 0509d2fc9c0149cb21668d45fff567eb524a49b4) iwl7000-tree: 7726f6a41e33303a32a016358e8e3bd5daa5cb25 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I056d5921af1f4e1933502619a0b007454730352d Reviewed-on: https://chromium-review.googlesource.com/442612 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit ce32ca74c86648447439ef564dee883bce23566b) Reviewed-on: https://chromium-review.googlesource.com/449030 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/b04685b795e4187fe840f1dd73700d0e417d7b54/drivers/net/wireless/iwl7000/mac80211/tx.c
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dfb13104d993de4394e70bdf6617c53be09b190f commit dfb13104d993de4394e70bdf6617c53be09b190f Author: Matt Chen <matt.chen@intel.com> Date: Fri Mar 03 20:34:39 2017 CHROMIUM: iwl7000: mac80211: flush delayed work when enter suspend The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen <matt.chen@intel.com> (cherry picked from commit 835ed86aebb0b38738f097290a159ccc10583f5a) iwl7000-tree: 7bac424534a8e132f1c5257c2b770409059d6009 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I2f5e32c7fe7b9ddc3c6e91680abc001ecc9526d7 Reviewed-on: https://chromium-review.googlesource.com/442617 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 026dfb4ef627a7014bcfe73865a0507253be5205) Reviewed-on: https://chromium-review.googlesource.com/449031 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/dfb13104d993de4394e70bdf6617c53be09b190f/drivers/net/wireless/iwl7000/mac80211/pm.c
,
Mar 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/87f9ecd35840efed6252b6ddbc1a652e0183c313 commit 87f9ecd35840efed6252b6ddbc1a652e0183c313 Author: Johannes Berg <johannes.berg@intel.com> Date: Sat Mar 04 05:29:46 2017 CHROMIUM: iwl7000: mac80211: initialize fast-xmit 'info' later In ieee80211_xmit_fast(), 'info' is initialized to point to the skb that's passed in, but that skb may later be replaced by a clone (if it was shared), leading to an invalid pointer. This can lead to use-after-free and also later crashes since the real SKB's info->hw_queue doesn't get initialized properly. Fix this by assigning info only later, when it's needed, after the skb replacement (may have) happened. (that's not really the broken commit, but rather the one that enabled the broken code for our driver) Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 0509d2fc9c0149cb21668d45fff567eb524a49b4) iwl7000-tree: 7726f6a41e33303a32a016358e8e3bd5daa5cb25 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I6d50aeb403d1a1ce57bc8efcdacd4936e951bd0f Reviewed-on: https://chromium-review.googlesource.com/442507 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 1dadc871060c8be4d359dc30f613ab36b86c958b) Reviewed-on: https://chromium-review.googlesource.com/449035 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/87f9ecd35840efed6252b6ddbc1a652e0183c313/drivers/net/wireless/iwl7000/mac80211/tx.c
,
Mar 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/761e18aab0e7f72a1d97be43b5c7e26fe7146291 commit 761e18aab0e7f72a1d97be43b5c7e26fe7146291 Author: Matt Chen <matt.chen@intel.com> Date: Sat Mar 04 05:37:14 2017 CHROMIUM: iwl7000: mac80211: flush delayed work when enter suspend The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen <matt.chen@intel.com> (cherry picked from commit 835ed86aebb0b38738f097290a159ccc10583f5a) iwl7000-tree: 7bac424534a8e132f1c5257c2b770409059d6009 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I2f5e32c7fe7b9ddc3c6e91680abc001ecc9526d7 Reviewed-on: https://chromium-review.googlesource.com/442552 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 4405848f3d5f146f61485cbb6dad3c5efdd71817) Reviewed-on: https://chromium-review.googlesource.com/449034 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/761e18aab0e7f72a1d97be43b5c7e26fe7146291/drivers/net/wireless/iwl7000/mac80211/pm.c
,
Mar 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a0f69df17d334063a1807cb616559d2292dfa163 commit a0f69df17d334063a1807cb616559d2292dfa163 Author: Johannes Berg <johannes.berg@intel.com> Date: Sat Mar 04 05:37:18 2017 CHROMIUM: iwl7000: mac80211: initialize fast-xmit 'info' later In ieee80211_xmit_fast(), 'info' is initialized to point to the skb that's passed in, but that skb may later be replaced by a clone (if it was shared), leading to an invalid pointer. This can lead to use-after-free and also later crashes since the real SKB's info->hw_queue doesn't get initialized properly. Fix this by assigning info only later, when it's needed, after the skb replacement (may have) happened. (that's not really the broken commit, but rather the one that enabled the broken code for our driver) Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 0509d2fc9c0149cb21668d45fff567eb524a49b4) iwl7000-tree: 7726f6a41e33303a32a016358e8e3bd5daa5cb25 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I056d5921af1f4e1933502619a0b007454730352d Reviewed-on: https://chromium-review.googlesource.com/442605 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit ad3322eae3b593c11d404d55fd47d8c2c80836a7) Reviewed-on: https://chromium-review.googlesource.com/449032 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/a0f69df17d334063a1807cb616559d2292dfa163/drivers/net/wireless-3.8/iwl7000/mac80211/tx.c
,
Mar 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/bd69764e2af7c3953d2239d98cbc9f4cc117e240 commit bd69764e2af7c3953d2239d98cbc9f4cc117e240 Author: Matt Chen <matt.chen@intel.com> Date: Sat Mar 04 05:37:21 2017 CHROMIUM: iwl7000: mac80211: flush delayed work when enter suspend The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen <matt.chen@intel.com> (cherry picked from commit 835ed86aebb0b38738f097290a159ccc10583f5a) iwl7000-tree: 7bac424534a8e132f1c5257c2b770409059d6009 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I2f5e32c7fe7b9ddc3c6e91680abc001ecc9526d7 Reviewed-on: https://chromium-review.googlesource.com/442610 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit a95b445f3149765e80bc63c270e0f424afc3e2c3) Reviewed-on: https://chromium-review.googlesource.com/449033 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/bd69764e2af7c3953d2239d98cbc9f4cc117e240/drivers/net/wireless-3.8/iwl7000/mac80211/pm.c
,
Mar 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2a060d107fe46c53e48d3e0e253c092fb146b5a5 commit 2a060d107fe46c53e48d3e0e253c092fb146b5a5 Author: Matt Chen <matt.chen@intel.com> Date: Sat Mar 04 05:37:24 2017 CHROMIUM: iwl7000: mac80211: flush delayed work when enter suspend The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen <matt.chen@intel.com> (cherry picked from commit 835ed86aebb0b38738f097290a159ccc10583f5a) iwl7000-tree: 7bac424534a8e132f1c5257c2b770409059d6009 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I3b0d753c0171de16804f90523f44251bd43b82a0 Reviewed-on: https://chromium-review.googlesource.com/442512 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 483ac334d4113dde815e83f556731d3cff0740db) Reviewed-on: https://chromium-review.googlesource.com/450095 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/2a060d107fe46c53e48d3e0e253c092fb146b5a5/drivers/net/wireless/iwl7000/mac80211/pm.c
,
Mar 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/acffd88fee574b1ac76c27456fbcdb170e617fff commit acffd88fee574b1ac76c27456fbcdb170e617fff Author: Johannes Berg <johannes.berg@intel.com> Date: Sat Mar 04 05:40:38 2017 CHROMIUM: iwl7000: mac80211: initialize fast-xmit 'info' later In ieee80211_xmit_fast(), 'info' is initialized to point to the skb that's passed in, but that skb may later be replaced by a clone (if it was shared), leading to an invalid pointer. This can lead to use-after-free and also later crashes since the real SKB's info->hw_queue doesn't get initialized properly. Fix this by assigning info only later, when it's needed, after the skb replacement (may have) happened. (that's not really the broken commit, but rather the one that enabled the broken code for our driver) Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 0509d2fc9c0149cb21668d45fff567eb524a49b4) iwl7000-tree: 7726f6a41e33303a32a016358e8e3bd5daa5cb25 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> BUG= chromium:693295 TEST=None Change-Id: I056d5921af1f4e1933502619a0b007454730352d Reviewed-on: https://chromium-review.googlesource.com/442547 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 1e4d143f06d529219663db3635140414fbaf1286) Reviewed-on: https://chromium-review.googlesource.com/450096 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/acffd88fee574b1ac76c27456fbcdb170e617fff/drivers/net/wireless/iwl7000/mac80211/tx.c
,
Mar 4 2017
Marking as fixed, removing 'Merged-Approved' since all patches are merged to ToT and some of them to M57 (which met the bar). CC-ing test team. I'll try to come up with a test plan next week.
,
Mar 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8b99fc28bf052acd711d624981a6d92dc212f739 commit 8b99fc28bf052acd711d624981a6d92dc212f739 Author: Kirtika Ruchandani <kirtika@chromium.org> Date: Tue Mar 07 08:34:10 2017 CHROMIUM: iwl7000: chromeOS: fix Intel regulatory (de)registration This is a re-land of commit b4803ed63478, with the erroneous KERNEL_VERSION ifdefs removed. --- Since callers can assume, due to the way this works in the normal cfg80211, that the wiphy pointer is valid even when the device has been or is being unregistered, defer the intel regulatory deregistration until free. To make error cases work correctly, also do the registration at alloc. Also squashed with: "CHROMIUM: iwl7000: chromeOS: register Intel regulatory in register_hw() This partially reverts my previous change: moving the regulatory registration into alloc_hw() is broken since then by that point the REGULATORY_WIPHY_SELF_MANAGED flag can't have been set yet, and thus registration will be ignored. I originally moved the register to be symmetric with unregister (which moved to free), but since unregister is idempotent and doesn't care if you unregister something that was never actually registered, it's safe to register only in register_hw() and yet unregister in free_hw()." BUG= chromium:693295 TEST=Booted and connected to network on Reef (4.4) Change-Id: I3c1104fbd446fbbba50e02bbf5e9cb44e0cb0091 Signed-off-by: Johannes Berg <johannes.berg@intel.com> iwl7000-tree: e1fe68f6b717e5b376addae692345f7ccd44ecf0 iwl7000-tree: 2daba21d5948d9205a92f69ad6a9768df760e211 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/450861 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/8b99fc28bf052acd711d624981a6d92dc212f739/drivers/net/wireless/iwl7000/mac80211/main.c
,
May 30 2017
,
Aug 1 2017
,
Jan 22 2018
,
Aug 14
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by bugdroid1@chromium.org
, Feb 17 2017