From: Greg Kroah-Hartman Date: Mon, 29 Aug 2022 08:39:32 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v5.10.140~7 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=733aa3432f7dc028d53867cc9360e548a9de5c68;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch --- diff --git a/queue-5.4/perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch b/queue-5.4/perf-x86-intel-uncore-fix-broken-read_counter-for-snb-imc-pmu.patch new file mode 100644 index 00000000000..ac31b65346d --- /dev/null +++ b/queue-5.4/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 +@@ -575,6 +575,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, +@@ -594,7 +610,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.4/scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch b/queue-5.4/scsi-storvsc-remove-wq_mem_reclaim-from-storvsc_error_wq.patch new file mode 100644 index 00000000000..e525a68c5e3 --- /dev/null +++ b/queue-5.4/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 +@@ -1846,7 +1846,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) + goto err_out2; diff --git a/queue-5.4/series b/queue-5.4/series index 92918514750..1fe98d58e6d 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -44,3 +44,5 @@ s390-fix-double-free-of-gs-and-ri-cbs-on-fork-failure.patch acpi-processor-remove-freq-qos-request-for-all-cpus.patch mm-hugetlb-fix-hugetlb-not-supporting-softdirty-tracking.patch md-call-__md_stop_writes-in-md_stop.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