From: Greg Kroah-Hartman Date: Tue, 3 Nov 2020 11:15:26 +0000 (+0100) Subject: 4.19-stable patches X-Git-Tag: v4.14.204~43 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=795022341d94ab38c105a6dc22d9d58e89f6eb85;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: md-raid5-fix-oops-during-stripe-resizing.patch mmc-sdhci-acpi-amdi0040-set-sdhci_quirk2_preset_value_broken.patch perf-x86-amd-ibs-don-t-include-randomized-bits-in-get_ibs_op_count.patch perf-x86-amd-ibs-fix-raw-sample-data-accumulation.patch --- diff --git a/queue-4.19/md-raid5-fix-oops-during-stripe-resizing.patch b/queue-4.19/md-raid5-fix-oops-during-stripe-resizing.patch new file mode 100644 index 00000000000..4a52b7b9df5 --- /dev/null +++ b/queue-4.19/md-raid5-fix-oops-during-stripe-resizing.patch @@ -0,0 +1,75 @@ +From b44c018cdf748b96b676ba09fdbc5b34fc443ada Mon Sep 17 00:00:00 2001 +From: Song Liu +Date: Mon, 5 Oct 2020 09:35:21 -0700 +Subject: md/raid5: fix oops during stripe resizing + +From: Song Liu + +commit b44c018cdf748b96b676ba09fdbc5b34fc443ada upstream. + +KoWei reported crash during raid5 reshape: + +[ 1032.252932] Oops: 0002 [#1] SMP PTI +[...] +[ 1032.252943] RIP: 0010:memcpy_erms+0x6/0x10 +[...] +[ 1032.252947] RSP: 0018:ffffba1ac0c03b78 EFLAGS: 00010286 +[ 1032.252949] RAX: 0000784ac0000000 RBX: ffff91bec3d09740 RCX: 0000000000001000 +[ 1032.252951] RDX: 0000000000001000 RSI: ffff91be6781c000 RDI: 0000784ac0000000 +[ 1032.252953] RBP: ffffba1ac0c03bd8 R08: 0000000000001000 R09: ffffba1ac0c03bf8 +[ 1032.252954] R10: 0000000000000000 R11: 0000000000000000 R12: ffffba1ac0c03bf8 +[ 1032.252955] R13: 0000000000001000 R14: 0000000000000000 R15: 0000000000000000 +[ 1032.252958] FS: 0000000000000000(0000) GS:ffff91becf500000(0000) knlGS:0000000000000000 +[ 1032.252959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 1032.252961] CR2: 0000784ac0000000 CR3: 000000031780a002 CR4: 00000000001606e0 +[ 1032.252962] Call Trace: +[ 1032.252969] ? async_memcpy+0x179/0x1000 [async_memcpy] +[ 1032.252977] ? raid5_release_stripe+0x8e/0x110 [raid456] +[ 1032.252982] handle_stripe_expansion+0x15a/0x1f0 [raid456] +[ 1032.252988] handle_stripe+0x592/0x1270 [raid456] +[ 1032.252993] handle_active_stripes.isra.0+0x3cb/0x5a0 [raid456] +[ 1032.252999] raid5d+0x35c/0x550 [raid456] +[ 1032.253002] ? schedule+0x42/0xb0 +[ 1032.253006] ? schedule_timeout+0x10e/0x160 +[ 1032.253011] md_thread+0x97/0x160 +[ 1032.253015] ? wait_woken+0x80/0x80 +[ 1032.253019] kthread+0x104/0x140 +[ 1032.253022] ? md_start_sync+0x60/0x60 +[ 1032.253024] ? kthread_park+0x90/0x90 +[ 1032.253027] ret_from_fork+0x35/0x40 + +This is because cache_size_mutex was unlocked too early in resize_stripes, +which races with grow_one_stripe() that grow_one_stripe() allocates a +stripe with wrong pool_size. + +Fix this issue by unlocking cache_size_mutex after updating pool_size. + +Cc: # v4.4+ +Reported-by: KoWei Sung +Signed-off-by: Song Liu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid5.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -2417,8 +2417,6 @@ static int resize_stripes(struct r5conf + } else + err = -ENOMEM; + +- mutex_unlock(&conf->cache_size_mutex); +- + conf->slab_cache = sc; + conf->active_name = 1-conf->active_name; + +@@ -2441,6 +2439,8 @@ static int resize_stripes(struct r5conf + + if (!err) + conf->pool_size = newsize; ++ mutex_unlock(&conf->cache_size_mutex); ++ + return err; + } + diff --git a/queue-4.19/mmc-sdhci-acpi-amdi0040-set-sdhci_quirk2_preset_value_broken.patch b/queue-4.19/mmc-sdhci-acpi-amdi0040-set-sdhci_quirk2_preset_value_broken.patch new file mode 100644 index 00000000000..4397030c901 --- /dev/null +++ b/queue-4.19/mmc-sdhci-acpi-amdi0040-set-sdhci_quirk2_preset_value_broken.patch @@ -0,0 +1,80 @@ +From f23cc3ba491af77395cea3f9d51204398729f26b Mon Sep 17 00:00:00 2001 +From: Raul E Rangel +Date: Mon, 28 Sep 2020 15:59:20 -0600 +Subject: mmc: sdhci-acpi: AMDI0040: Set SDHCI_QUIRK2_PRESET_VALUE_BROKEN + +From: Raul E Rangel + +commit f23cc3ba491af77395cea3f9d51204398729f26b upstream. + +This change fixes HS400 tuning for devices with invalid presets. + +SDHCI presets are not currently used for eMMC HS/HS200/HS400, but are +used for DDR52. The HS400 retuning sequence is: + + HS400->DDR52->HS->HS200->Perform Tuning->HS->HS400 + +This means that when HS400 tuning happens, we transition through DDR52 +for a very brief period. This causes presets to be enabled +unintentionally and stay enabled when transitioning back to HS200 or +HS400. Some firmware has invalid presets, so we end up with driver +strengths that can cause I/O problems. + +Fixes: 34597a3f60b1 ("mmc: sdhci-acpi: Add support for ACPI HID of AMD Controller with HS400") +Signed-off-by: Raul E Rangel +Acked-by: Adrian Hunter +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200928154718.1.Icc21d4b2f354e83e26e57e270dc952f5fe0b0a40@changeid +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-acpi.c | 37 +++++++++++++++++++++++++++++++++++++ + 1 file changed, 37 insertions(+) + +--- a/drivers/mmc/host/sdhci-acpi.c ++++ b/drivers/mmc/host/sdhci-acpi.c +@@ -546,6 +546,43 @@ static int sdhci_acpi_emmc_amd_probe_slo + (host->mmc->caps & MMC_CAP_1_8V_DDR)) + host->mmc->caps2 = MMC_CAP2_HS400_1_8V; + ++ /* ++ * There are two types of presets out in the wild: ++ * 1) Default/broken presets. ++ * These presets have two sets of problems: ++ * a) The clock divisor for SDR12, SDR25, and SDR50 is too small. ++ * This results in clock frequencies that are 2x higher than ++ * acceptable. i.e., SDR12 = 25 MHz, SDR25 = 50 MHz, SDR50 = ++ * 100 MHz.x ++ * b) The HS200 and HS400 driver strengths don't match. ++ * By default, the SDR104 preset register has a driver strength of ++ * A, but the (internal) HS400 preset register has a driver ++ * strength of B. As part of initializing HS400, HS200 tuning ++ * needs to be performed. Having different driver strengths ++ * between tuning and operation is wrong. It results in different ++ * rise/fall times that lead to incorrect sampling. ++ * 2) Firmware with properly initialized presets. ++ * These presets have proper clock divisors. i.e., SDR12 => 12MHz, ++ * SDR25 => 25 MHz, SDR50 => 50 MHz. Additionally the HS200 and ++ * HS400 preset driver strengths match. ++ * ++ * Enabling presets for HS400 doesn't work for the following reasons: ++ * 1) sdhci_set_ios has a hard coded list of timings that are used ++ * to determine if presets should be enabled. ++ * 2) sdhci_get_preset_value is using a non-standard register to ++ * read out HS400 presets. The AMD controller doesn't support this ++ * non-standard register. In fact, it doesn't expose the HS400 ++ * preset register anywhere in the SDHCI memory map. This results ++ * in reading a garbage value and using the wrong presets. ++ * ++ * Since HS400 and HS200 presets must be identical, we could ++ * instead use the the SDR104 preset register. ++ * ++ * If the above issues are resolved we could remove this quirk for ++ * firmware that that has valid presets (i.e., SDR12 <= 12 MHz). ++ */ ++ host->quirks2 |= SDHCI_QUIRK2_PRESET_VALUE_BROKEN; ++ + host->mmc_host_ops.select_drive_strength = amd_select_drive_strength; + host->mmc_host_ops.set_ios = amd_set_ios; + return 0; diff --git a/queue-4.19/perf-x86-amd-ibs-don-t-include-randomized-bits-in-get_ibs_op_count.patch b/queue-4.19/perf-x86-amd-ibs-don-t-include-randomized-bits-in-get_ibs_op_count.patch new file mode 100644 index 00000000000..9d6daf81475 --- /dev/null +++ b/queue-4.19/perf-x86-amd-ibs-don-t-include-randomized-bits-in-get_ibs_op_count.patch @@ -0,0 +1,51 @@ +From 680d69635005ba0e58fe3f4c52fc162b8fc743b0 Mon Sep 17 00:00:00 2001 +From: Kim Phillips +Date: Tue, 8 Sep 2020 16:47:37 -0500 +Subject: perf/x86/amd/ibs: Don't include randomized bits in get_ibs_op_count() + +From: Kim Phillips + +commit 680d69635005ba0e58fe3f4c52fc162b8fc743b0 upstream. + +get_ibs_op_count() adds hardware's current count (IbsOpCurCnt) bits +to its count regardless of hardware's valid status. + +According to the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54, +if the counter rolls over, valid status is set, and the lower 7 bits +of IbsOpCurCnt are randomized by hardware. + +Don't include those bits in the driver's event count. + +Fixes: 8b1e13638d46 ("perf/x86-ibs: Fix usage of IBS op current count") +Signed-off-by: Kim Phillips +Signed-off-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/events/amd/ibs.c | 12 ++++++++---- + 1 file changed, 8 insertions(+), 4 deletions(-) + +--- a/arch/x86/events/amd/ibs.c ++++ b/arch/x86/events/amd/ibs.c +@@ -347,11 +347,15 @@ static u64 get_ibs_op_count(u64 config) + { + u64 count = 0; + ++ /* ++ * If the internal 27-bit counter rolled over, the count is MaxCnt ++ * and the lower 7 bits of CurCnt are randomized. ++ * Otherwise CurCnt has the full 27-bit current counter value. ++ */ + if (config & IBS_OP_VAL) +- count += (config & IBS_OP_MAX_CNT) << 4; /* cnt rolled over */ +- +- if (ibs_caps & IBS_CAPS_RDWROPCNT) +- count += (config & IBS_OP_CUR_CNT) >> 32; ++ count = (config & IBS_OP_MAX_CNT) << 4; ++ else if (ibs_caps & IBS_CAPS_RDWROPCNT) ++ count = (config & IBS_OP_CUR_CNT) >> 32; + + return count; + } diff --git a/queue-4.19/perf-x86-amd-ibs-fix-raw-sample-data-accumulation.patch b/queue-4.19/perf-x86-amd-ibs-fix-raw-sample-data-accumulation.patch new file mode 100644 index 00000000000..dc110826d97 --- /dev/null +++ b/queue-4.19/perf-x86-amd-ibs-fix-raw-sample-data-accumulation.patch @@ -0,0 +1,80 @@ +From 36e1be8ada994d509538b3b1d0af8b63c351e729 Mon Sep 17 00:00:00 2001 +From: Kim Phillips +Date: Tue, 8 Sep 2020 16:47:38 -0500 +Subject: perf/x86/amd/ibs: Fix raw sample data accumulation + +From: Kim Phillips + +commit 36e1be8ada994d509538b3b1d0af8b63c351e729 upstream. + +Neither IbsBrTarget nor OPDATA4 are populated in IBS Fetch mode. +Don't accumulate them into raw sample user data in that case. + +Also, in Fetch mode, add saving the IBS Fetch Control Extended MSR. + +Technically, there is an ABI change here with respect to the IBS raw +sample data format, but I don't see any perf driver version information +being included in perf.data file headers, but, existing users can detect +whether the size of the sample record has reduced by 8 bytes to +determine whether the IBS driver has this fix. + +Fixes: 904cb3677f3a ("perf/x86/amd/ibs: Update IBS MSRs and feature definitions") +Reported-by: Stephane Eranian +Signed-off-by: Kim Phillips +Signed-off-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20200908214740.18097-6-kim.phillips@amd.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/events/amd/ibs.c | 26 ++++++++++++++++---------- + arch/x86/include/asm/msr-index.h | 1 + + 2 files changed, 17 insertions(+), 10 deletions(-) + +--- a/arch/x86/events/amd/ibs.c ++++ b/arch/x86/events/amd/ibs.c +@@ -647,18 +647,24 @@ fail: + perf_ibs->offset_max, + offset + 1); + } while (offset < offset_max); ++ /* ++ * Read IbsBrTarget, IbsOpData4, and IbsExtdCtl separately ++ * depending on their availability. ++ * Can't add to offset_max as they are staggered ++ */ + if (event->attr.sample_type & PERF_SAMPLE_RAW) { +- /* +- * Read IbsBrTarget and IbsOpData4 separately +- * depending on their availability. +- * Can't add to offset_max as they are staggered +- */ +- if (ibs_caps & IBS_CAPS_BRNTRGT) { +- rdmsrl(MSR_AMD64_IBSBRTARGET, *buf++); +- size++; ++ if (perf_ibs == &perf_ibs_op) { ++ if (ibs_caps & IBS_CAPS_BRNTRGT) { ++ rdmsrl(MSR_AMD64_IBSBRTARGET, *buf++); ++ size++; ++ } ++ if (ibs_caps & IBS_CAPS_OPDATA4) { ++ rdmsrl(MSR_AMD64_IBSOPDATA4, *buf++); ++ size++; ++ } + } +- if (ibs_caps & IBS_CAPS_OPDATA4) { +- rdmsrl(MSR_AMD64_IBSOPDATA4, *buf++); ++ if (perf_ibs == &perf_ibs_fetch && (ibs_caps & IBS_CAPS_FETCHCTLEXTD)) { ++ rdmsrl(MSR_AMD64_ICIBSEXTDCTL, *buf++); + size++; + } + } +--- a/arch/x86/include/asm/msr-index.h ++++ b/arch/x86/include/asm/msr-index.h +@@ -377,6 +377,7 @@ + #define MSR_AMD64_IBSOP_REG_MASK ((1UL<