--- /dev/null
+From 043770bf51cb31d12919dac8554441070fd561a8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 7 Nov 2020 14:32:54 +0100
+Subject: ACPI: button: Add DMI quirk for Medion Akoya E2228T
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+[ Upstream commit 7daaa06357bf7f1874b62bb1ea9d66a51d4e567e ]
+
+The Medion Akoya E2228T's ACPI _LID implementation is quite broken,
+it has the same issues as the one from the Medion Akoya E2215T:
+
+1. For notifications it uses an ActiveLow Edge GpioInt, rather then
+ an ActiveBoth one, meaning that the device is only notified when the
+ lid is closed, not when it is opened.
+
+2. Matching with this its _LID method simply always returns 0 (closed)
+
+In order for the Linux LID code to work properly with this implementation,
+the lid_init_state selection needs to be set to ACPI_BUTTON_LID_INIT_OPEN,
+add a DMI quirk for this.
+
+While working on this I also found out that the MD60### part of the model
+number differs per country/batch while all of the E2215T and E2228T models
+have this issue, so also remove the " MD60198" part from the E2215T quirk.
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/button.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
+index 690bfe67e643d..ee7a7da276ddf 100644
+--- a/drivers/acpi/button.c
++++ b/drivers/acpi/button.c
+@@ -85,7 +85,18 @@ static const struct dmi_system_id lid_blacklst[] = {
+ */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "MEDION"),
+- DMI_MATCH(DMI_PRODUCT_NAME, "E2215T MD60198"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "E2215T"),
++ },
++ .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN,
++ },
++ {
++ /*
++ * Medion Akoya E2228T, notification of the LID device only
++ * happens on close, not on open and _LID always returns closed.
++ */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "MEDION"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "E2228T"),
+ },
+ .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN,
+ },
+--
+2.27.0
+
--- /dev/null
+From 40453dbe62f89e0ce89e8499486d5fb09868b7b8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Nov 2020 11:14:26 +0000
+Subject: arm64: errata: Fix handling of 1418040 with late CPU onlining
+
+From: Will Deacon <will@kernel.org>
+
+[ Upstream commit f969f03888b9438fdb227b6460d99ede5737326d ]
+
+In a surprising turn of events, it transpires that CPU capabilities
+configured as ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE are never set as the
+result of late-onlining. Therefore our handling of erratum 1418040 does
+not get activated if it is not required by any of the boot CPUs, even
+though we allow late-onlining of an affected CPU.
+
+In order to get things working again, replace the cpus_have_const_cap()
+invocation with an explicit check for the current CPU using
+this_cpu_has_cap().
+
+Cc: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
+Cc: Stephen Boyd <swboyd@chromium.org>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Acked-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20201106114952.10032-1-will@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/include/asm/cpufeature.h | 2 ++
+ arch/arm64/kernel/process.c | 5 ++---
+ 2 files changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
+index 10d3048dec7c2..ccae05da98a7f 100644
+--- a/arch/arm64/include/asm/cpufeature.h
++++ b/arch/arm64/include/asm/cpufeature.h
+@@ -262,6 +262,8 @@ extern struct arm64_ftr_reg arm64_ftr_reg_ctrel0;
+ /*
+ * CPU feature detected at boot time based on feature of one or more CPUs.
+ * All possible conflicts for a late CPU are ignored.
++ * NOTE: this means that a late CPU with the feature will *not* cause the
++ * capability to be advertised by cpus_have_*cap()!
+ */
+ #define ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE \
+ (ARM64_CPUCAP_SCOPE_LOCAL_CPU | \
+diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
+index 10190c4b16dc4..7d7cfa128b71b 100644
+--- a/arch/arm64/kernel/process.c
++++ b/arch/arm64/kernel/process.c
+@@ -511,14 +511,13 @@ static void erratum_1418040_thread_switch(struct task_struct *prev,
+ bool prev32, next32;
+ u64 val;
+
+- if (!(IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040) &&
+- cpus_have_const_cap(ARM64_WORKAROUND_1418040)))
++ if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040))
+ return;
+
+ prev32 = is_compat_thread(task_thread_info(prev));
+ next32 = is_compat_thread(task_thread_info(next));
+
+- if (prev32 == next32)
++ if (prev32 == next32 || !this_cpu_has_cap(ARM64_WORKAROUND_1418040))
+ return;
+
+ val = read_sysreg(cntkctl_el1);
+--
+2.27.0
+
--- /dev/null
+From 22ac9403503955d162405e45fba159825bd86ba2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Nov 2020 09:57:55 +0000
+Subject: arm64: psci: Avoid printing in cpu_psci_cpu_die()
+
+From: Will Deacon <will@kernel.org>
+
+[ Upstream commit 891deb87585017d526b67b59c15d38755b900fea ]
+
+cpu_psci_cpu_die() is called in the context of the dying CPU, which
+will no longer be online or tracked by RCU. It is therefore not generally
+safe to call printk() if the PSCI "cpu off" request fails, so remove the
+pr_crit() invocation.
+
+Cc: Qian Cai <cai@redhat.com>
+Cc: "Paul E. McKenney" <paulmck@kernel.org>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Link: https://lore.kernel.org/r/20201106103602.9849-2-will@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/kernel/psci.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
+index 43ae4e0c968f6..62d2bda7adb80 100644
+--- a/arch/arm64/kernel/psci.c
++++ b/arch/arm64/kernel/psci.c
+@@ -66,7 +66,6 @@ static int cpu_psci_cpu_disable(unsigned int cpu)
+
+ static void cpu_psci_cpu_die(unsigned int cpu)
+ {
+- int ret;
+ /*
+ * There are no known implementations of PSCI actually using the
+ * power state field, pass a sensible default for now.
+@@ -74,9 +73,7 @@ static void cpu_psci_cpu_die(unsigned int cpu)
+ u32 state = PSCI_POWER_STATE_TYPE_POWER_DOWN <<
+ PSCI_0_2_POWER_STATE_TYPE_SHIFT;
+
+- ret = psci_ops.cpu_off(state);
+-
+- pr_crit("unable to power off CPU%u (%d)\n", cpu, ret);
++ psci_ops.cpu_off(state);
+ }
+
+ static int cpu_psci_cpu_kill(unsigned int cpu)
+--
+2.27.0
+
--- /dev/null
+From bede33e3bb3f846c591b05232bf7bcf5a82e1db9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Nov 2020 10:25:49 +0000
+Subject: arm64: smp: Tell RCU about CPUs that fail to come online
+
+From: Will Deacon <will@kernel.org>
+
+[ Upstream commit 04e613ded8c26489b3e0f9101b44462f780d1a35 ]
+
+Commit ce3d31ad3cac ("arm64/smp: Move rcu_cpu_starting() earlier") ensured
+that RCU is informed early about incoming CPUs that might end up calling
+into printk() before they are online. However, if such a CPU fails the
+early CPU feature compatibility checks in check_local_cpu_capabilities(),
+then it will be powered off or parked without informing RCU, leading to
+an endless stream of stalls:
+
+ | rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
+ | rcu: 2-O...: (0 ticks this GP) idle=002/1/0x4000000000000000 softirq=0/0 fqs=2593
+ | (detected by 0, t=5252 jiffies, g=9317, q=136)
+ | Task dump for CPU 2:
+ | task:swapper/2 state:R running task stack: 0 pid: 0 ppid: 1 flags:0x00000028
+ | Call trace:
+ | ret_from_fork+0x0/0x30
+
+Ensure that the dying CPU invokes rcu_report_dead() prior to being powered
+off or parked.
+
+Cc: Qian Cai <cai@redhat.com>
+Cc: "Paul E. McKenney" <paulmck@kernel.org>
+Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
+Suggested-by: Qian Cai <cai@redhat.com>
+Link: https://lore.kernel.org/r/20201105222242.GA8842@willie-the-truck
+Link: https://lore.kernel.org/r/20201106103602.9849-3-will@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/kernel/smp.c | 1 +
+ kernel/rcu/tree.c | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
+index 426409e0d0713..987220ac4cfef 100644
+--- a/arch/arm64/kernel/smp.c
++++ b/arch/arm64/kernel/smp.c
+@@ -388,6 +388,7 @@ void cpu_die_early(void)
+
+ /* Mark this CPU absent */
+ set_cpu_present(cpu, 0);
++ rcu_report_dead(cpu);
+
+ #ifdef CONFIG_HOTPLUG_CPU
+ update_cpu_boot_status(CPU_KILL_ME);
+diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
+index 62e59596a30a0..1b1d2b09efa9b 100644
+--- a/kernel/rcu/tree.c
++++ b/kernel/rcu/tree.c
+@@ -3157,7 +3157,6 @@ void rcu_cpu_starting(unsigned int cpu)
+ smp_mb(); /* Ensure RCU read-side usage follows above initialization. */
+ }
+
+-#ifdef CONFIG_HOTPLUG_CPU
+ /*
+ * The outgoing function has no further need of RCU, so remove it from
+ * the rcu_node tree's ->qsmaskinitnext bit masks.
+@@ -3197,6 +3196,7 @@ void rcu_report_dead(unsigned int cpu)
+ per_cpu(rcu_cpu_started, cpu) = 0;
+ }
+
++#ifdef CONFIG_HOTPLUG_CPU
+ /*
+ * The outgoing CPU has just passed through the dying-idle state, and we
+ * are being invoked from the CPU that was IPIed to continue the offline
+--
+2.27.0
+
--- /dev/null
+From 5961f01ba0608b0a91c752f5fd49b5bc2f5336d2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 8 Nov 2020 17:27:41 +0800
+Subject: gfs2: fix possible reference leak in gfs2_check_blk_type
+
+From: Zhang Qilong <zhangqilong3@huawei.com>
+
+[ Upstream commit bc923818b190c8b63c91a47702969c8053574f5b ]
+
+In the fail path of gfs2_check_blk_type, forgetting to call
+gfs2_glock_dq_uninit will result in rgd_gh reference leak.
+
+Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
+Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/gfs2/rgrp.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
+index 3d5aa0c10a4c1..5d9d93ca0db70 100644
+--- a/fs/gfs2/rgrp.c
++++ b/fs/gfs2/rgrp.c
+@@ -2574,13 +2574,13 @@ int gfs2_check_blk_type(struct gfs2_sbd *sdp, u64 no_addr, unsigned int type)
+
+ rbm.rgd = rgd;
+ error = gfs2_rbm_from_block(&rbm, no_addr);
+- if (WARN_ON_ONCE(error))
+- goto fail;
+-
+- if (gfs2_testbit(&rbm, false) != type)
+- error = -ESTALE;
++ if (!WARN_ON_ONCE(error)) {
++ if (gfs2_testbit(&rbm, false) != type)
++ error = -ESTALE;
++ }
+
+ gfs2_glock_dq_uninit(&rgd_gh);
++
+ fail:
+ return error;
+ }
+--
+2.27.0
+
--- /dev/null
+From 6ddbe9e8ac5a10e748d48b81281a0a6d45ce2c9a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 Nov 2020 16:46:43 +0000
+Subject: hwmon: (pwm-fan) Fix RPM calculation
+
+From: Paul Barker <pbarker@konsulko.com>
+
+[ Upstream commit fd8feec665fef840277515a5c2b9b7c3e3970fad ]
+
+To convert the number of pulses counted into an RPM estimation, we need
+to divide by the width of our measurement interval instead of
+multiplying by it. If the width of the measurement interval is zero we
+don't update the RPM value to avoid dividing by zero.
+
+We also don't need to do 64-bit division, with 32-bits we can handle a
+fan running at over 4 million RPM.
+
+Signed-off-by: Paul Barker <pbarker@konsulko.com>
+Link: https://lore.kernel.org/r/20201111164643.7087-1-pbarker@konsulko.com
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hwmon/pwm-fan.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
+index 42ffd2e5182d5..c88ce77fe6763 100644
+--- a/drivers/hwmon/pwm-fan.c
++++ b/drivers/hwmon/pwm-fan.c
+@@ -54,16 +54,18 @@ static irqreturn_t pulse_handler(int irq, void *dev_id)
+ static void sample_timer(struct timer_list *t)
+ {
+ struct pwm_fan_ctx *ctx = from_timer(ctx, t, rpm_timer);
++ unsigned int delta = ktime_ms_delta(ktime_get(), ctx->sample_start);
+ int pulses;
+- u64 tmp;
+
+- pulses = atomic_read(&ctx->pulses);
+- atomic_sub(pulses, &ctx->pulses);
+- tmp = (u64)pulses * ktime_ms_delta(ktime_get(), ctx->sample_start) * 60;
+- do_div(tmp, ctx->pulses_per_revolution * 1000);
+- ctx->rpm = tmp;
++ if (delta) {
++ pulses = atomic_read(&ctx->pulses);
++ atomic_sub(pulses, &ctx->pulses);
++ ctx->rpm = (unsigned int)(pulses * 1000 * 60) /
++ (ctx->pulses_per_revolution * delta);
++
++ ctx->sample_start = ktime_get();
++ }
+
+- ctx->sample_start = ktime_get();
+ mod_timer(&ctx->rpm_timer, jiffies + HZ);
+ }
+
+--
+2.27.0
+
--- /dev/null
+From a500b0e95f89afe71eb22b18b1c810a6018fe67d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 13 Oct 2020 14:37:30 +0800
+Subject: pinctrl: rockchip: enable gpio pclk for rockchip_gpio_to_irq
+
+From: Jianqun Xu <jay.xu@rock-chips.com>
+
+[ Upstream commit 63fbf8013b2f6430754526ef9594f229c7219b1f ]
+
+There need to enable pclk_gpio when do irq_create_mapping, since it will
+do access to gpio controller.
+
+Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
+Reviewed-by: Heiko Stuebner <heiko@sntech.de>
+Reviewed-by: Kever Yang<kever.yang@rock-chips.com>
+Link: https://lore.kernel.org/r/20201013063731.3618-3-jay.xu@rock-chips.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pinctrl/pinctrl-rockchip.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
+index 1bd8840e11a6e..930edfc32f597 100644
+--- a/drivers/pinctrl/pinctrl-rockchip.c
++++ b/drivers/pinctrl/pinctrl-rockchip.c
+@@ -2811,7 +2811,9 @@ static int rockchip_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
+ if (!bank->domain)
+ return -ENXIO;
+
++ clk_enable(bank->clk);
+ virq = irq_create_mapping(bank->domain, offset);
++ clk_disable(bank->clk);
+
+ return (virq) ? : -ENXIO;
+ }
+--
+2.27.0
+
--- /dev/null
+From 317daf4be2aef38c8ed44375305d9a98779ed5dd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 2 Nov 2020 22:24:39 -0800
+Subject: scsi: ufs: Fix unbalanced scsi_block_reqs_cnt caused by ufshcd_hold()
+
+From: Can Guo <cang@codeaurora.org>
+
+[ Upstream commit da3fecb0040324c08f1587e5bff1f15f36be1872 ]
+
+The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be
+decreased back in ufshcd_ungate_work() in a paired way. However, if
+specific ufshcd_hold/release sequences are met, it is possible that
+scsi_block_reqs_cnt is increased twice but only one ungate work is
+queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() and
+ufshcd_ungate_work() in a paired way, increase it only if queue_work()
+returns true.
+
+Link: https://lore.kernel.org/r/1604384682-15837-2-git-send-email-cang@codeaurora.org
+Reviewed-by: Hongwu Su <hongwus@codeaurora.org>
+Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
+Reviewed-by: Bean Huo <beanhuo@micron.com>
+Signed-off-by: Can Guo <cang@codeaurora.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/ufs/ufshcd.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
+index d538b3d4f74a5..0772327f87d93 100644
+--- a/drivers/scsi/ufs/ufshcd.c
++++ b/drivers/scsi/ufs/ufshcd.c
+@@ -1569,12 +1569,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
+ */
+ /* fallthrough */
+ case CLKS_OFF:
+- ufshcd_scsi_block_requests(hba);
+ hba->clk_gating.state = REQ_CLKS_ON;
+ trace_ufshcd_clk_gating(dev_name(hba->dev),
+ hba->clk_gating.state);
+- queue_work(hba->clk_gating.clk_gating_workq,
+- &hba->clk_gating.ungate_work);
++ if (queue_work(hba->clk_gating.clk_gating_workq,
++ &hba->clk_gating.ungate_work))
++ ufshcd_scsi_block_requests(hba);
+ /*
+ * fall through to check if we should wait for this
+ * work to be done or not.
+--
+2.27.0
+
--- /dev/null
+From f672d5eba3c4ccc1d553e4b23d6712bfdfcf6138 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 12 Oct 2020 12:47:13 -0700
+Subject: selftests: kvm: Fix the segment descriptor layout to match the actual
+ layout
+
+From: Aaron Lewis <aaronlewis@google.com>
+
+[ Upstream commit df11f7dd5834146defa448acba097e8d7703cc42 ]
+
+Fix the layout of 'struct desc64' to match the layout described in the
+SDM Vol 3, Chapter 3 "Protected-Mode Memory Management", section 3.4.5
+"Segment Descriptors", Figure 3-8 "Segment Descriptor". The test added
+later in this series relies on this and crashes if this layout is not
+correct.
+
+Signed-off-by: Aaron Lewis <aaronlewis@google.com>
+Reviewed-by: Alexander Graf <graf@amazon.com>
+Message-Id: <20201012194716.3950330-2-aaronlewis@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/kvm/include/x86_64/processor.h | 2 +-
+ tools/testing/selftests/kvm/lib/x86_64/processor.c | 3 ++-
+ 2 files changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/tools/testing/selftests/kvm/include/x86_64/processor.h b/tools/testing/selftests/kvm/include/x86_64/processor.h
+index ff234018219cf..aead07c24afcf 100644
+--- a/tools/testing/selftests/kvm/include/x86_64/processor.h
++++ b/tools/testing/selftests/kvm/include/x86_64/processor.h
+@@ -57,7 +57,7 @@ enum x86_register {
+ struct desc64 {
+ uint16_t limit0;
+ uint16_t base0;
+- unsigned base1:8, s:1, type:4, dpl:2, p:1;
++ unsigned base1:8, type:4, s:1, dpl:2, p:1;
+ unsigned limit1:4, avl:1, l:1, db:1, g:1, base2:8;
+ uint32_t base3;
+ uint32_t zero1;
+diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c
+index 6698cb741e10a..7d8f7fc736467 100644
+--- a/tools/testing/selftests/kvm/lib/x86_64/processor.c
++++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c
+@@ -446,11 +446,12 @@ static void kvm_seg_fill_gdt_64bit(struct kvm_vm *vm, struct kvm_segment *segp)
+ desc->limit0 = segp->limit & 0xFFFF;
+ desc->base0 = segp->base & 0xFFFF;
+ desc->base1 = segp->base >> 16;
+- desc->s = segp->s;
+ desc->type = segp->type;
++ desc->s = segp->s;
+ desc->dpl = segp->dpl;
+ desc->p = segp->present;
+ desc->limit1 = segp->limit >> 16;
++ desc->avl = segp->avl;
+ desc->l = segp->l;
+ desc->db = segp->db;
+ desc->g = segp->g;
+--
+2.27.0
+
net-usb-qmi_wwan-set-dtr-quirk-for-mr400.patch
net-ncsi-fix-netlink-registration.patch
net-ftgmac100-fix-crash-when-removing-driver.patch
+pinctrl-rockchip-enable-gpio-pclk-for-rockchip_gpio_.patch
+scsi-ufs-fix-unbalanced-scsi_block_reqs_cnt-caused-b.patch
+selftests-kvm-fix-the-segment-descriptor-layout-to-m.patch
+acpi-button-add-dmi-quirk-for-medion-akoya-e2228t.patch
+arm64-errata-fix-handling-of-1418040-with-late-cpu-o.patch
+arm64-psci-avoid-printing-in-cpu_psci_cpu_die.patch
+arm64-smp-tell-rcu-about-cpus-that-fail-to-come-onli.patch
+vfs-remove-lockdep-bogosity-in-__sb_start_write.patch
+gfs2-fix-possible-reference-leak-in-gfs2_check_blk_t.patch
+hwmon-pwm-fan-fix-rpm-calculation.patch
--- /dev/null
+From 55b840e33cef87b0b809b4d87392792666f16dbe Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Nov 2020 16:49:29 -0800
+Subject: vfs: remove lockdep bogosity in __sb_start_write
+
+From: Darrick J. Wong <darrick.wong@oracle.com>
+
+[ Upstream commit 22843291efc986ce7722610073fcf85a39b4cb13 ]
+
+__sb_start_write has some weird looking lockdep code that claims to
+exist to handle nested freeze locking requests from xfs. The code as
+written seems broken -- if we think we hold a read lock on any of the
+higher freeze levels (e.g. we hold SB_FREEZE_WRITE and are trying to
+lock SB_FREEZE_PAGEFAULT), it converts a blocking lock attempt into a
+trylock.
+
+However, it's not correct to downgrade a blocking lock attempt to a
+trylock unless the downgrading code or the callers are prepared to deal
+with that situation. Neither __sb_start_write nor its callers handle
+this at all. For example:
+
+sb_start_pagefault ignores the return value completely, with the result
+that if xfs_filemap_fault loses a race with a different thread trying to
+fsfreeze, it will proceed without pagefault freeze protection (thereby
+breaking locking rules) and then unlocks the pagefault freeze lock that
+it doesn't own on its way out (thereby corrupting the lock state), which
+leads to a system hang shortly afterwards.
+
+Normally, this won't happen because our ownership of a read lock on a
+higher freeze protection level blocks fsfreeze from grabbing a write
+lock on that higher level. *However*, if lockdep is offline,
+lock_is_held_type unconditionally returns 1, which means that
+percpu_rwsem_is_held returns 1, which means that __sb_start_write
+unconditionally converts blocking freeze lock attempts into trylocks,
+even when we *don't* hold anything that would block a fsfreeze.
+
+Apparently this all held together until 5.10-rc1, when bugs in lockdep
+caused lockdep to shut itself off early in an fstests run, and once
+fstests gets to the "race writes with freezer" tests, kaboom. This
+might explain the long trail of vanishingly infrequent livelocks in
+fstests after lockdep goes offline that I've never been able to
+diagnose.
+
+We could fix it by spinning on the trylock if wait==true, but AFAICT the
+locking works fine if lockdep is not built at all (and I didn't see any
+complaints running fstests overnight), so remove this snippet entirely.
+
+NOTE: Commit f4b554af9931 in 2015 created the current weird logic (which
+used to exist in a different form in commit 5accdf82ba25c from 2012) in
+__sb_start_write. XFS solved this whole problem in the late 2.6 era by
+creating a variant of transactions (XFS_TRANS_NO_WRITECOUNT) that don't
+grab intwrite freeze protection, thus making lockdep's solution
+unnecessary. The commit claims that Dave Chinner explained that the
+trylock hack + comment could be removed, but nobody ever did.
+
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/super.c | 33 ++++-----------------------------
+ 1 file changed, 4 insertions(+), 29 deletions(-)
+
+diff --git a/fs/super.c b/fs/super.c
+index a288cd60d2aed..877532baf513d 100644
+--- a/fs/super.c
++++ b/fs/super.c
+@@ -1647,36 +1647,11 @@ EXPORT_SYMBOL(__sb_end_write);
+ */
+ int __sb_start_write(struct super_block *sb, int level, bool wait)
+ {
+- bool force_trylock = false;
+- int ret = 1;
++ if (!wait)
++ return percpu_down_read_trylock(sb->s_writers.rw_sem + level-1);
+
+-#ifdef CONFIG_LOCKDEP
+- /*
+- * We want lockdep to tell us about possible deadlocks with freezing
+- * but it's it bit tricky to properly instrument it. Getting a freeze
+- * protection works as getting a read lock but there are subtle
+- * problems. XFS for example gets freeze protection on internal level
+- * twice in some cases, which is OK only because we already hold a
+- * freeze protection also on higher level. Due to these cases we have
+- * to use wait == F (trylock mode) which must not fail.
+- */
+- if (wait) {
+- int i;
+-
+- for (i = 0; i < level - 1; i++)
+- if (percpu_rwsem_is_held(sb->s_writers.rw_sem + i)) {
+- force_trylock = true;
+- break;
+- }
+- }
+-#endif
+- if (wait && !force_trylock)
+- percpu_down_read(sb->s_writers.rw_sem + level-1);
+- else
+- ret = percpu_down_read_trylock(sb->s_writers.rw_sem + level-1);
+-
+- WARN_ON(force_trylock && !ret);
+- return ret;
++ percpu_down_read(sb->s_writers.rw_sem + level-1);
++ return 1;
+ }
+ EXPORT_SYMBOL(__sb_start_write);
+
+--
+2.27.0
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
