From: Greg Kroah-Hartman Date: Mon, 29 Aug 2022 08:49:13 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.10.140~6 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=17632c85d6e424a426780382c23d8bf66d4fa416;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: arm64-fix-match_list-for-erratum-1286807-on-arm-cortex-a76.patch blk-mq-fix-io-hung-due-to-missing-commit_rqs.patch documentation-abi-mention-retbleed-vulnerability-info-file-for-sysfs.patch perf-python-fix-build-when-python_config-is-user-supplied.patch perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch scsi-ufs-core-enable-link-lost-interrupt.patch --- diff --git a/queue-5.10/arm64-fix-match_list-for-erratum-1286807-on-arm-cortex-a76.patch b/queue-5.10/arm64-fix-match_list-for-erratum-1286807-on-arm-cortex-a76.patch new file mode 100644 index 00000000000..0e1fb179698 --- /dev/null +++ b/queue-5.10/arm64-fix-match_list-for-erratum-1286807-on-arm-cortex-a76.patch @@ -0,0 +1,37 @@ +From 5e1e087457c94ad7fafbe1cf6f774c6999ee29d4 Mon Sep 17 00:00:00 2001 +From: Zenghui Yu +Date: Tue, 9 Aug 2022 12:38:48 +0800 +Subject: arm64: Fix match_list for erratum 1286807 on Arm Cortex-A76 + +From: Zenghui Yu + +commit 5e1e087457c94ad7fafbe1cf6f774c6999ee29d4 upstream. + +Since commit 51f559d66527 ("arm64: Enable repeat tlbi workaround on KRYO4XX +gold CPUs"), we failed to detect erratum 1286807 on Cortex-A76 because its +entry in arm64_repeat_tlbi_list[] was accidently corrupted by this commit. + +Fix this issue by creating a separate entry for Kryo4xx Gold. + +Fixes: 51f559d66527 ("arm64: Enable repeat tlbi workaround on KRYO4XX gold CPUs") +Cc: Shreyas K K +Signed-off-by: Zenghui Yu +Acked-by: Marc Zyngier +Link: https://lore.kernel.org/r/20220809043848.969-1-yuzenghui@huawei.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/cpu_errata.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/arm64/kernel/cpu_errata.c ++++ b/arch/arm64/kernel/cpu_errata.c +@@ -220,6 +220,8 @@ static const struct arm64_cpu_capabiliti + #ifdef CONFIG_ARM64_ERRATUM_1286807 + { + ERRATA_MIDR_RANGE(MIDR_CORTEX_A76, 0, 0, 3, 0), ++ }, ++ { + /* Kryo4xx Gold (rcpe to rfpe) => (r0p0 to r3p0) */ + ERRATA_MIDR_RANGE(MIDR_QCOM_KRYO_4XX_GOLD, 0xc, 0xe, 0xf, 0xe), + }, diff --git a/queue-5.10/blk-mq-fix-io-hung-due-to-missing-commit_rqs.patch b/queue-5.10/blk-mq-fix-io-hung-due-to-missing-commit_rqs.patch new file mode 100644 index 00000000000..99438c76411 --- /dev/null +++ b/queue-5.10/blk-mq-fix-io-hung-due-to-missing-commit_rqs.patch @@ -0,0 +1,94 @@ +From 65fac0d54f374625b43a9d6ad1f2c212bd41f518 Mon Sep 17 00:00:00 2001 +From: Yu Kuai +Date: Tue, 26 Jul 2022 20:22:24 +0800 +Subject: blk-mq: fix io hung due to missing commit_rqs + +From: Yu Kuai + +commit 65fac0d54f374625b43a9d6ad1f2c212bd41f518 upstream. + +Currently, in virtio_scsi, if 'bd->last' is not set to true while +dispatching request, such io will stay in driver's queue, and driver +will wait for block layer to dispatch more rqs. However, if block +layer failed to dispatch more rq, it should trigger commit_rqs to +inform driver. + +There is a problem in blk_mq_try_issue_list_directly() that commit_rqs +won't be called: + +// assume that queue_depth is set to 1, list contains two rq +blk_mq_try_issue_list_directly + blk_mq_request_issue_directly + // dispatch first rq + // last is false + __blk_mq_try_issue_directly + blk_mq_get_dispatch_budget + // succeed to get first budget + __blk_mq_issue_directly + scsi_queue_rq + cmd->flags |= SCMD_LAST + virtscsi_queuecommand + kick = (sc->flags & SCMD_LAST) != 0 + // kick is false, first rq won't issue to disk + queued++ + + blk_mq_request_issue_directly + // dispatch second rq + __blk_mq_try_issue_directly + blk_mq_get_dispatch_budget + // failed to get second budget + ret == BLK_STS_RESOURCE + blk_mq_request_bypass_insert + // errors is still 0 + + if (!list_empty(list) || errors && ...) + // won't pass, commit_rqs won't be called + +In this situation, first rq relied on second rq to dispatch, while +second rq relied on first rq to complete, thus they will both hung. + +Fix the problem by also treat 'BLK_STS_*RESOURCE' as 'errors' since +it means that request is not queued successfully. + +Same problem exists in blk_mq_dispatch_rq_list(), 'BLK_STS_*RESOURCE' +can't be treated as 'errors' here, fix the problem by calling +commit_rqs if queue_rq return 'BLK_STS_*RESOURCE'. + +Fixes: d666ba98f849 ("blk-mq: add mq_ops->commit_rqs()") +Signed-off-by: Yu Kuai +Reviewed-by: Ming Lei +Link: https://lore.kernel.org/r/20220726122224.1790882-1-yukuai1@huaweicloud.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/blk-mq.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/block/blk-mq.c ++++ b/block/blk-mq.c +@@ -1402,7 +1402,8 @@ out: + /* If we didn't flush the entire list, we could have told the driver + * there was more coming, but that turned out to be a lie. + */ +- if ((!list_empty(list) || errors) && q->mq_ops->commit_rqs && queued) ++ if ((!list_empty(list) || errors || needs_resource || ++ ret == BLK_STS_DEV_RESOURCE) && q->mq_ops->commit_rqs && queued) + q->mq_ops->commit_rqs(hctx); + /* + * Any items that need requeuing? Stuff them into hctx->dispatch, +@@ -2080,6 +2081,7 @@ void blk_mq_try_issue_list_directly(stru + list_del_init(&rq->queuelist); + ret = blk_mq_request_issue_directly(rq, list_empty(list)); + if (ret != BLK_STS_OK) { ++ errors++; + if (ret == BLK_STS_RESOURCE || + ret == BLK_STS_DEV_RESOURCE) { + blk_mq_request_bypass_insert(rq, false, +@@ -2087,7 +2089,6 @@ void blk_mq_try_issue_list_directly(stru + break; + } + blk_mq_end_request(rq, ret); +- errors++; + } else + queued++; + } diff --git a/queue-5.10/documentation-abi-mention-retbleed-vulnerability-info-file-for-sysfs.patch b/queue-5.10/documentation-abi-mention-retbleed-vulnerability-info-file-for-sysfs.patch new file mode 100644 index 00000000000..0a9a35a56f5 --- /dev/null +++ b/queue-5.10/documentation-abi-mention-retbleed-vulnerability-info-file-for-sysfs.patch @@ -0,0 +1,35 @@ +From 00da0cb385d05a89226e150a102eb49d8abb0359 Mon Sep 17 00:00:00 2001 +From: Salvatore Bonaccorso +Date: Mon, 1 Aug 2022 11:15:30 +0200 +Subject: Documentation/ABI: Mention retbleed vulnerability info file for sysfs + +From: Salvatore Bonaccorso + +commit 00da0cb385d05a89226e150a102eb49d8abb0359 upstream. + +While reporting for the AMD retbleed vulnerability was added in + + 6b80b59b3555 ("x86/bugs: Report AMD retbleed vulnerability") + +the new sysfs file was not mentioned so far in the ABI documentation for +sysfs-devices-system-cpu. Fix that. + +Fixes: 6b80b59b3555 ("x86/bugs: Report AMD retbleed vulnerability") +Signed-off-by: Salvatore Bonaccorso +Signed-off-by: Borislav Petkov +Link: https://lore.kernel.org/r/20220801091529.325327-1-carnil@debian.org +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + + 1 file changed, 1 insertion(+) + +--- a/Documentation/ABI/testing/sysfs-devices-system-cpu ++++ b/Documentation/ABI/testing/sysfs-devices-system-cpu +@@ -511,6 +511,7 @@ What: /sys/devices/system/cpu/vulnerabi + /sys/devices/system/cpu/vulnerabilities/tsx_async_abort + /sys/devices/system/cpu/vulnerabilities/itlb_multihit + /sys/devices/system/cpu/vulnerabilities/mmio_stale_data ++ /sys/devices/system/cpu/vulnerabilities/retbleed + Date: January 2018 + Contact: Linux kernel mailing list + Description: Information about CPU vulnerabilities diff --git a/queue-5.10/perf-python-fix-build-when-python_config-is-user-supplied.patch b/queue-5.10/perf-python-fix-build-when-python_config-is-user-supplied.patch new file mode 100644 index 00000000000..890e3323c0d --- /dev/null +++ b/queue-5.10/perf-python-fix-build-when-python_config-is-user-supplied.patch @@ -0,0 +1,53 @@ +From bc9e7fe313d5e56d4d5f34bcc04d1165f94f86fb Mon Sep 17 00:00:00 2001 +From: James Clark +Date: Thu, 28 Jul 2022 10:39:46 +0100 +Subject: perf python: Fix build when PYTHON_CONFIG is user supplied + +From: James Clark + +commit bc9e7fe313d5e56d4d5f34bcc04d1165f94f86fb upstream. + +The previous change to Python autodetection had a small mistake where +the auto value was used to determine the Python binary, rather than the +user supplied value. The Python binary is only used for one part of the +build process, rather than the final linking, so it was producing +correct builds in most scenarios, especially when the auto detected +value matched what the user wanted, or the system only had a valid set +of Pythons. + +Change it so that the Python binary path is derived from either the +PYTHON_CONFIG value or PYTHON value, depending on what is specified by +the user. This was the original intention. + +This error was spotted in a build failure an odd cross compilation +environment after commit 4c41cb46a732fe82 ("perf python: Prefer +python3") was merged. + +Fixes: 630af16eee495f58 ("perf tools: Use Python devtools for version autodetection rather than runtime") +Signed-off-by: James Clark +Acked-by: Ian Rogers +Cc: Alexander Shishkin +Cc: Ingo Molnar +Cc: James Clark +Cc: Jiri Olsa +Cc: Mark Rutland +Cc: Namhyung Kim +Cc: Peter Zijlstra +Link: https://lore.kernel.org/r/20220728093946.1337642-1-james.clark@arm.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman +--- + tools/perf/Makefile.config | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/perf/Makefile.config ++++ b/tools/perf/Makefile.config +@@ -248,7 +248,7 @@ endif + # defined. get-executable-or-default fails with an error if the first argument is supplied but + # doesn't exist. + override PYTHON_CONFIG := $(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON_AUTO)) +-override PYTHON := $(call get-executable-or-default,PYTHON,$(subst -config,,$(PYTHON_AUTO))) ++override PYTHON := $(call get-executable-or-default,PYTHON,$(subst -config,,$(PYTHON_CONFIG))) + + grep-libs = $(filter -l%,$(1)) + strip-libs = $(filter-out -l%,$(1)) diff --git a/queue-5.10/perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch b/queue-5.10/perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch new file mode 100644 index 00000000000..d4763e603ac --- /dev/null +++ b/queue-5.10/perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch @@ -0,0 +1,85 @@ +From 11745ecfe8fea4b4a4c322967a7605d2ecbd5080 Mon Sep 17 00:00:00 2001 +From: Stephane Eranian +Date: Wed, 3 Aug 2022 09:00:31 -0700 +Subject: perf/x86/intel/uncore: Fix broken read_counter() for SNB IMC PMU + +From: Stephane Eranian + +commit 11745ecfe8fea4b4a4c322967a7605d2ecbd5080 upstream. + +Existing code was generating bogus counts for the SNB IMC bandwidth counters: + +$ perf stat -a -I 1000 -e uncore_imc/data_reads/,uncore_imc/data_writes/ + 1.000327813 1,024.03 MiB uncore_imc/data_reads/ + 1.000327813 20.73 MiB uncore_imc/data_writes/ + 2.000580153 261,120.00 MiB uncore_imc/data_reads/ + 2.000580153 23.28 MiB uncore_imc/data_writes/ + +The problem was introduced by commit: + 07ce734dd8ad ("perf/x86/intel/uncore: Clean up client IMC") + +Where the read_counter callback was replace to point to the generic +uncore_mmio_read_counter() function. + +The SNB IMC counters are freerunnig 32-bit counters laid out contiguously in +MMIO. But uncore_mmio_read_counter() is using a readq() call to read from +MMIO therefore reading 64-bit from MMIO. Although this is okay for the +uncore_perf_event_update() function because it is shifting the value based +on the actual counter width to compute a delta, it is not okay for the +uncore_pmu_event_start() which is simply reading the counter and therefore +priming the event->prev_count with a bogus value which is responsible for +causing bogus deltas in the perf stat command above. + +The fix is to reintroduce the custom callback for read_counter for the SNB +IMC PMU and use readl() instead of readq(). With the change the output of +perf stat is back to normal: +$ perf stat -a -I 1000 -e uncore_imc/data_reads/,uncore_imc/data_writes/ + 1.000120987 296.94 MiB uncore_imc/data_reads/ + 1.000120987 138.42 MiB uncore_imc/data_writes/ + 2.000403144 175.91 MiB uncore_imc/data_reads/ + 2.000403144 68.50 MiB uncore_imc/data_writes/ + +Fixes: 07ce734dd8ad ("perf/x86/intel/uncore: Clean up client IMC") +Signed-off-by: Stephane Eranian +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Kan Liang +Link: https://lore.kernel.org/r/20220803160031.1379788-1-eranian@google.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/events/intel/uncore_snb.c | 18 +++++++++++++++++- + 1 file changed, 17 insertions(+), 1 deletion(-) + +--- a/arch/x86/events/intel/uncore_snb.c ++++ b/arch/x86/events/intel/uncore_snb.c +@@ -657,6 +657,22 @@ int snb_pci2phy_map_init(int devid) + return 0; + } + ++static u64 snb_uncore_imc_read_counter(struct intel_uncore_box *box, struct perf_event *event) ++{ ++ struct hw_perf_event *hwc = &event->hw; ++ ++ /* ++ * SNB IMC counters are 32-bit and are laid out back to back ++ * in MMIO space. Therefore we must use a 32-bit accessor function ++ * using readq() from uncore_mmio_read_counter() causes problems ++ * because it is reading 64-bit at a time. This is okay for the ++ * uncore_perf_event_update() function because it drops the upper ++ * 32-bits but not okay for plain uncore_read_counter() as invoked ++ * in uncore_pmu_event_start(). ++ */ ++ return (u64)readl(box->io_addr + hwc->event_base); ++} ++ + static struct pmu snb_uncore_imc_pmu = { + .task_ctx_nr = perf_invalid_context, + .event_init = snb_uncore_imc_event_init, +@@ -676,7 +692,7 @@ static struct intel_uncore_ops snb_uncor + .disable_event = snb_uncore_imc_disable_event, + .enable_event = snb_uncore_imc_enable_event, + .hw_config = snb_uncore_imc_hw_config, +- .read_counter = uncore_mmio_read_counter, ++ .read_counter = snb_uncore_imc_read_counter, + }; + + static struct intel_uncore_type snb_uncore_imc = { diff --git a/queue-5.10/scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch b/queue-5.10/scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch new file mode 100644 index 00000000000..c88f9279373 --- /dev/null +++ b/queue-5.10/scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch @@ -0,0 +1,67 @@ +From d957e7ffb2c72410bcc1a514153a46719255a5da Mon Sep 17 00:00:00 2001 +From: Saurabh Sengar +Date: Thu, 4 Aug 2022 08:55:34 -0700 +Subject: scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq + +From: Saurabh Sengar + +commit d957e7ffb2c72410bcc1a514153a46719255a5da upstream. + +storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it +doesn't need to make forward progress under memory pressure. Marking this +workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a +non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following +warning: + +[ 14.506347] ------------[ cut here ]------------ +[ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn +[ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 +[ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu +[ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 +[ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun +[ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 + <-snip-> +[ 14.506408] Call Trace: +[ 14.506412] __flush_work+0xf1/0x1c0 +[ 14.506414] __cancel_work_timer+0x12f/0x1b0 +[ 14.506417] ? kernfs_put+0xf0/0x190 +[ 14.506418] cancel_delayed_work_sync+0x13/0x20 +[ 14.506420] disk_block_events+0x78/0x80 +[ 14.506421] del_gendisk+0x3d/0x2f0 +[ 14.506423] sr_remove+0x28/0x70 +[ 14.506427] device_release_driver_internal+0xef/0x1c0 +[ 14.506428] device_release_driver+0x12/0x20 +[ 14.506429] bus_remove_device+0xe1/0x150 +[ 14.506431] device_del+0x167/0x380 +[ 14.506432] __scsi_remove_device+0x11d/0x150 +[ 14.506433] scsi_remove_device+0x26/0x40 +[ 14.506434] storvsc_remove_lun+0x40/0x60 +[ 14.506436] process_one_work+0x209/0x400 +[ 14.506437] worker_thread+0x34/0x400 +[ 14.506439] kthread+0x121/0x140 +[ 14.506440] ? process_one_work+0x400/0x400 +[ 14.506441] ? kthread_park+0x90/0x90 +[ 14.506443] ret_from_fork+0x35/0x40 +[ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]--- + +Link: https://lore.kernel.org/r/1659628534-17539-1-git-send-email-ssengar@linux.microsoft.com +Fixes: 436ad9413353 ("scsi: storvsc: Allow only one remove lun work item to be issued per lun") +Reviewed-by: Michael Kelley +Signed-off-by: Saurabh Sengar +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/storvsc_drv.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/scsi/storvsc_drv.c ++++ b/drivers/scsi/storvsc_drv.c +@@ -1997,7 +1997,7 @@ static int storvsc_probe(struct hv_devic + */ + host_dev->handle_error_wq = + alloc_ordered_workqueue("storvsc_error_wq_%d", +- WQ_MEM_RECLAIM, ++ 0, + host->host_no); + if (!host_dev->handle_error_wq) { + ret = -ENOMEM; diff --git a/queue-5.10/scsi-ufs-core-enable-link-lost-interrupt.patch b/queue-5.10/scsi-ufs-core-enable-link-lost-interrupt.patch new file mode 100644 index 00000000000..0d261af4471 --- /dev/null +++ b/queue-5.10/scsi-ufs-core-enable-link-lost-interrupt.patch @@ -0,0 +1,38 @@ +From 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269 Mon Sep 17 00:00:00 2001 +From: Kiwoong Kim +Date: Tue, 2 Aug 2022 10:42:31 +0900 +Subject: scsi: ufs: core: Enable link lost interrupt + +From: Kiwoong Kim + +commit 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269 upstream. + +Link lost is treated as fatal error with commit c99b9b230149 ("scsi: ufs: +Treat link loss as fatal error"), but the event isn't registered as +interrupt source. Enable it. + +Link: https://lore.kernel.org/r/1659404551-160958-1-git-send-email-kwmad.kim@samsung.com +Fixes: c99b9b230149 ("scsi: ufs: Treat link loss as fatal error") +Reviewed-by: Bart Van Assche +Signed-off-by: Kiwoong Kim +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/ufs/ufshci.h | 6 +----- + 1 file changed, 1 insertion(+), 5 deletions(-) + +--- a/drivers/scsi/ufs/ufshci.h ++++ b/drivers/scsi/ufs/ufshci.h +@@ -129,11 +129,7 @@ enum { + + #define UFSHCD_UIC_MASK (UIC_COMMAND_COMPL | UFSHCD_UIC_PWR_MASK) + +-#define UFSHCD_ERROR_MASK (UIC_ERROR |\ +- DEVICE_FATAL_ERROR |\ +- CONTROLLER_FATAL_ERROR |\ +- SYSTEM_BUS_FATAL_ERROR |\ +- CRYPTO_ENGINE_FATAL_ERROR) ++#define UFSHCD_ERROR_MASK (UIC_ERROR | INT_FATAL_ERRORS) + + #define INT_FATAL_ERRORS (DEVICE_FATAL_ERROR |\ + CONTROLLER_FATAL_ERROR |\ diff --git a/queue-5.10/series b/queue-5.10/series index a663c3152e4..54c366ba51f 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -76,3 +76,10 @@ xen-privcmd-fix-error-exit-of-privcmd_ioctl_dm_op.patch mm-hugetlb-fix-hugetlb-not-supporting-softdirty-tracking.patch revert-md-raid-destroy-the-bitmap-after-destroying-the-thread.patch md-call-__md_stop_writes-in-md_stop.patch +arm64-fix-match_list-for-erratum-1286807-on-arm-cortex-a76.patch +documentation-abi-mention-retbleed-vulnerability-info-file-for-sysfs.patch +blk-mq-fix-io-hung-due-to-missing-commit_rqs.patch +perf-python-fix-build-when-python_config-is-user-supplied.patch +perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch +scsi-ufs-core-enable-link-lost-interrupt.patch +scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch