--- /dev/null
+From 4f4fd7c5798bbdd5a03a60f6269cf1177fbd11ef Mon Sep 17 00:00:00 2001
+From: Nigel Croxon <ncroxon@redhat.com>
+Date: Fri, 29 Mar 2019 10:46:15 -0700
+Subject: Don't jump to compute_result state from check_result state
+
+From: Nigel Croxon <ncroxon@redhat.com>
+
+commit 4f4fd7c5798bbdd5a03a60f6269cf1177fbd11ef upstream.
+
+Changing state from check_state_check_result to
+check_state_compute_result not only is unsafe but also doesn't
+appear to serve a valid purpose. A raid6 check should only be
+pushing out extra writes if doing repair and a mis-match occurs.
+The stripe dev management will already try and do repair writes
+for failing sectors.
+
+This patch makes the raid6 check_state_check_result handling
+work more like raid5's. If somehow too many failures for a
+check, just quit the check operation for the stripe. When any
+checks pass, don't try and use check_state_compute_result for
+a purpose it isn't needed for and is unsafe for. Just mark the
+stripe as in sync for passing its parity checks and let the
+stripe dev read/write code and the bad blocks list do their
+job handling I/O errors.
+
+Repro steps from Xiao:
+
+These are the steps to reproduce this problem:
+1. redefined OPT_MEDIUM_ERR_ADDR to 12000 in scsi_debug.c
+2. insmod scsi_debug.ko dev_size_mb=11000 max_luns=1 num_tgts=1
+3. mdadm --create /dev/md127 --level=6 --raid-devices=5 /dev/sde1 /dev/sde2 /dev/sde3 /dev/sde5 /dev/sde6
+sde is the disk created by scsi_debug
+4. echo "2" >/sys/module/scsi_debug/parameters/opts
+5. raid-check
+
+It panic:
+[ 4854.730899] md: data-check of RAID array md127
+[ 4854.857455] sd 5:0:0:0: [sdr] tag#80 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
+[ 4854.859246] sd 5:0:0:0: [sdr] tag#80 Sense Key : Medium Error [current]
+[ 4854.860694] sd 5:0:0:0: [sdr] tag#80 Add. Sense: Unrecovered read error
+[ 4854.862207] sd 5:0:0:0: [sdr] tag#80 CDB: Read(10) 28 00 00 00 2d 88 00 04 00 00
+[ 4854.864196] print_req_error: critical medium error, dev sdr, sector 11656 flags 0
+[ 4854.867409] sd 5:0:0:0: [sdr] tag#100 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
+[ 4854.869469] sd 5:0:0:0: [sdr] tag#100 Sense Key : Medium Error [current]
+[ 4854.871206] sd 5:0:0:0: [sdr] tag#100 Add. Sense: Unrecovered read error
+[ 4854.872858] sd 5:0:0:0: [sdr] tag#100 CDB: Read(10) 28 00 00 00 2e e0 00 00 08 00
+[ 4854.874587] print_req_error: critical medium error, dev sdr, sector 12000 flags 4000
+[ 4854.876456] sd 5:0:0:0: [sdr] tag#101 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
+[ 4854.878552] sd 5:0:0:0: [sdr] tag#101 Sense Key : Medium Error [current]
+[ 4854.880278] sd 5:0:0:0: [sdr] tag#101 Add. Sense: Unrecovered read error
+[ 4854.881846] sd 5:0:0:0: [sdr] tag#101 CDB: Read(10) 28 00 00 00 2e e8 00 00 08 00
+[ 4854.883691] print_req_error: critical medium error, dev sdr, sector 12008 flags 4000
+[ 4854.893927] sd 5:0:0:0: [sdr] tag#166 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
+[ 4854.896002] sd 5:0:0:0: [sdr] tag#166 Sense Key : Medium Error [current]
+[ 4854.897561] sd 5:0:0:0: [sdr] tag#166 Add. Sense: Unrecovered read error
+[ 4854.899110] sd 5:0:0:0: [sdr] tag#166 CDB: Read(10) 28 00 00 00 2e e0 00 00 10 00
+[ 4854.900989] print_req_error: critical medium error, dev sdr, sector 12000 flags 0
+[ 4854.902757] md/raid:md127: read error NOT corrected!! (sector 9952 on sdr1).
+[ 4854.904375] md/raid:md127: read error NOT corrected!! (sector 9960 on sdr1).
+[ 4854.906201] ------------[ cut here ]------------
+[ 4854.907341] kernel BUG at drivers/md/raid5.c:4190!
+
+raid5.c:4190 above is this BUG_ON:
+
+ handle_parity_checks6()
+ ...
+ BUG_ON(s->uptodate < disks - 1); /* We don't need Q to recover */
+
+Cc: <stable@vger.kernel.org> # v3.16+
+OriginalAuthor: David Jeffery <djeffery@redhat.com>
+Cc: Xiao Ni <xni@redhat.com>
+Tested-by: David Jeffery <djeffery@redhat.com>
+Signed-off-by: David Jeffy <djeffery@redhat.com>
+Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid5.c | 19 ++++---------------
+ 1 file changed, 4 insertions(+), 15 deletions(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -4233,26 +4233,15 @@ static void handle_parity_checks6(struct
+ case check_state_check_result:
+ sh->check_state = check_state_idle;
+
++ if (s->failed > 1)
++ break;
+ /* handle a successful check operation, if parity is correct
+ * we are done. Otherwise update the mismatch count and repair
+ * parity if !MD_RECOVERY_CHECK
+ */
+ if (sh->ops.zero_sum_result == 0) {
+- /* both parities are correct */
+- if (!s->failed)
+- set_bit(STRIPE_INSYNC, &sh->state);
+- else {
+- /* in contrast to the raid5 case we can validate
+- * parity, but still have a failure to write
+- * back
+- */
+- sh->check_state = check_state_compute_result;
+- /* Returning at this point means that we may go
+- * off and bring p and/or q uptodate again so
+- * we make sure to check zero_sum_result again
+- * to verify if p or q need writeback
+- */
+- }
++ /* Any parity checked was correct */
++ set_bit(STRIPE_INSYNC, &sh->state);
+ } else {
+ atomic64_add(STRIPE_SECTORS, &conf->mddev->resync_mismatches);
+ if (test_bit(MD_RECOVERY_CHECK, &conf->mddev->recovery)) {
--- /dev/null
+From d2ab99403ee00d8014e651728a4702ea1ae5e52c Mon Sep 17 00:00:00 2001
+From: zhong jiang <zhongjiang@huawei.com>
+Date: Mon, 8 Apr 2019 12:07:17 +0800
+Subject: mm/memory_hotplug: Do not unlock when fails to take the device_hotplug_lock
+
+From: zhong jiang <zhongjiang@huawei.com>
+
+commit d2ab99403ee00d8014e651728a4702ea1ae5e52c upstream.
+
+When adding the memory by probing memory block in sysfs interface, there is an
+obvious issue that we will unlock the device_hotplug_lock when fails to takes it.
+
+That issue was introduced in Commit 8df1d0e4a265
+("mm/memory_hotplug: make add_memory() take the device_hotplug_lock")
+
+We should drop out in time when fails to take the device_hotplug_lock.
+
+Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock")
+Reported-by: Yang yingliang <yangyingliang@huawei.com>
+Signed-off-by: zhong jiang <zhongjiang@huawei.com>
+Reviewed-by: Oscar Salvador <osalvador@suse.de>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/base/memory.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/base/memory.c
++++ b/drivers/base/memory.c
+@@ -512,7 +512,7 @@ static ssize_t probe_store(struct device
+ MIN_MEMORY_BLOCK_SIZE * sections_per_block);
+
+ if (ret)
+- goto out;
++ return ret;
+
+ ret = count;
+ out:
--- /dev/null
+From 6b583201fa219b7b1b6aebd8966c8fd9357ef9f4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20=C5=A0tetiar?= <ynezz@true.cz>
+Date: Thu, 11 Apr 2019 20:13:30 +0200
+Subject: mwl8k: Fix rate_idx underflow
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Petr Štetiar <ynezz@true.cz>
+
+commit 6b583201fa219b7b1b6aebd8966c8fd9357ef9f4 upstream.
+
+It was reported on OpenWrt bug tracking system[1], that several users
+are affected by the endless reboot of their routers if they configure
+5GHz interface with channel 44 or 48.
+
+The reboot loop is caused by the following excessive number of WARN_ON
+messages:
+
+ WARNING: CPU: 0 PID: 0 at backports-4.19.23-1/net/mac80211/rx.c:4516
+ ieee80211_rx_napi+0x1fc/0xa54 [mac80211]
+
+as the messages are being correctly emitted by the following guard:
+
+ case RX_ENC_LEGACY:
+ if (WARN_ON(status->rate_idx >= sband->n_bitrates))
+
+as the rate_idx is in this case erroneously set to 251 (0xfb). This fix
+simply converts previously used magic number to proper constant and
+guards against substraction which is leading to the currently observed
+underflow.
+
+1. https://bugs.openwrt.org/index.php?do=details&task_id=2218
+
+Fixes: 854783444bab ("mwl8k: properly set receive status rate index on 5 GHz receive")
+Cc: <stable@vger.kernel.org>
+Tested-by: Eubert Bao <bunnier@gmail.com>
+Reported-by: Eubert Bao <bunnier@gmail.com>
+Signed-off-by: Petr Štetiar <ynezz@true.cz>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/marvell/mwl8k.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/wireless/marvell/mwl8k.c
++++ b/drivers/net/wireless/marvell/mwl8k.c
+@@ -441,6 +441,9 @@ static const struct ieee80211_rate mwl8k
+ #define MWL8K_CMD_UPDATE_STADB 0x1123
+ #define MWL8K_CMD_BASTREAM 0x1125
+
++#define MWL8K_LEGACY_5G_RATE_OFFSET \
++ (ARRAY_SIZE(mwl8k_rates_24) - ARRAY_SIZE(mwl8k_rates_50))
++
+ static const char *mwl8k_cmd_name(__le16 cmd, char *buf, int bufsize)
+ {
+ u16 command = le16_to_cpu(cmd);
+@@ -1016,8 +1019,9 @@ mwl8k_rxd_ap_process(void *_rxd, struct
+
+ if (rxd->channel > 14) {
+ status->band = NL80211_BAND_5GHZ;
+- if (!(status->encoding == RX_ENC_HT))
+- status->rate_idx -= 5;
++ if (!(status->encoding == RX_ENC_HT) &&
++ status->rate_idx >= MWL8K_LEGACY_5G_RATE_OFFSET)
++ status->rate_idx -= MWL8K_LEGACY_5G_RATE_OFFSET;
+ } else {
+ status->band = NL80211_BAND_2GHZ;
+ }
+@@ -1124,8 +1128,9 @@ mwl8k_rxd_sta_process(void *_rxd, struct
+
+ if (rxd->channel > 14) {
+ status->band = NL80211_BAND_5GHZ;
+- if (!(status->encoding == RX_ENC_HT))
+- status->rate_idx -= 5;
++ if (!(status->encoding == RX_ENC_HT) &&
++ status->rate_idx >= MWL8K_LEGACY_5G_RATE_OFFSET)
++ status->rate_idx -= MWL8K_LEGACY_5G_RATE_OFFSET;
+ } else {
+ status->band = NL80211_BAND_2GHZ;
+ }
--- /dev/null
+From 84242b82d81c54e009a2aaa74d3d9eff70babf56 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Tue, 16 Apr 2019 10:17:22 -0500
+Subject: rtlwifi: rtl8723ae: Fix missing break in switch statement
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 84242b82d81c54e009a2aaa74d3d9eff70babf56 upstream.
+
+Add missing break statement in order to prevent the code from falling
+through to case 0x1025, and erroneously setting rtlhal->oem_id to
+RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and
+none of the cases in switch (rtlefuse->eeprom_smid) match.
+
+This bug was found thanks to the ongoing efforts to enable
+-Wimplicit-fallthrough.
+
+Fixes: 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
++++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
+@@ -1697,6 +1697,7 @@ static void _rtl8723e_read_adapter_info(
+ rtlhal->oem_id = RT_CID_819X_LENOVO;
+ break;
+ }
++ break;
+ case 0x1025:
+ rtlhal->oem_id = RT_CID_819X_ACER;
+ break;
net-mvpp2-fix-validate-for-ppv2.1.patch
drm-rockchip-fix-for-mailbox-read-validation.patch
cw1200-fix-missing-unlock-on-error-in-cw1200_hw_scan.patch
+mwl8k-fix-rate_idx-underflow.patch
+rtlwifi-rtl8723ae-fix-missing-break-in-switch-statement.patch
+mm-memory_hotplug-do-not-unlock-when-fails-to-take-the-device_hotplug_lock.patch
+don-t-jump-to-compute_result-state-from-check_result-state.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
