--- /dev/null
+From b44c018cdf748b96b676ba09fdbc5b34fc443ada Mon Sep 17 00:00:00 2001
+From: Song Liu <songliubraving@fb.com>
+Date: Mon, 5 Oct 2020 09:35:21 -0700
+Subject: md/raid5: fix oops during stripe resizing
+
+From: Song Liu <songliubraving@fb.com>
+
+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: <stable@vger.kernel.org> # v4.4+
+Reported-by: KoWei Sung <winders@amazon.com>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
--- /dev/null
+From f23cc3ba491af77395cea3f9d51204398729f26b Mon Sep 17 00:00:00 2001
+From: Raul E Rangel <rrangel@chromium.org>
+Date: Mon, 28 Sep 2020 15:59:20 -0600
+Subject: mmc: sdhci-acpi: AMDI0040: Set SDHCI_QUIRK2_PRESET_VALUE_BROKEN
+
+From: Raul E Rangel <rrangel@chromium.org>
+
+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 <rrangel@chromium.org>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200928154718.1.Icc21d4b2f354e83e26e57e270dc952f5fe0b0a40@changeid
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 680d69635005ba0e58fe3f4c52fc162b8fc743b0 Mon Sep 17 00:00:00 2001
+From: Kim Phillips <kim.phillips@amd.com>
+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 <kim.phillips@amd.com>
+
+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 <kim.phillips@amd.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 36e1be8ada994d509538b3b1d0af8b63c351e729 Mon Sep 17 00:00:00 2001
+From: Kim Phillips <kim.phillips@amd.com>
+Date: Tue, 8 Sep 2020 16:47:38 -0500
+Subject: perf/x86/amd/ibs: Fix raw sample data accumulation
+
+From: Kim Phillips <kim.phillips@amd.com>
+
+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 <stephane.eranian@google.com>
+Signed-off-by: Kim Phillips <kim.phillips@amd.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20200908214740.18097-6-kim.phillips@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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<<MSR_AMD64_IBSOP_REG_COUNT)-1)
+ #define MSR_AMD64_IBSCTL 0xc001103a
+ #define MSR_AMD64_IBSBRTARGET 0xc001103b
++#define MSR_AMD64_ICIBSEXTDCTL 0xc001103c
+ #define MSR_AMD64_IBSOPDATA4 0xc001103d
+ #define MSR_AMD64_IBS_REG_COUNT_MAX 8 /* includes MSR_AMD64_IBSBRTARGET */
+ #define MSR_AMD64_SEV 0xc0010131
nbd-make-the-config-put-is-called-before-the-notifyi.patch
sgl_alloc_order-fix-memory-leak.patch
nvme-rdma-fix-crash-when-connect-rejected.patch
+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
projects / thirdparty / kernel / stable-queue.git / commitdiff
