From: Sasha Levin Date: Sun, 22 Nov 2020 17:03:29 +0000 (-0500) Subject: Fixes for 4.19 X-Git-Tag: v4.4.246~42 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8cb985f0ddba93e89dd8b84459603edb7cd28ff0;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.19 Signed-off-by: Sasha Levin --- diff --git a/queue-4.19/acpi-button-add-dmi-quirk-for-medion-akoya-e2228t.patch b/queue-4.19/acpi-button-add-dmi-quirk-for-medion-akoya-e2228t.patch new file mode 100644 index 00000000000..18972e4a8e8 --- /dev/null +++ b/queue-4.19/acpi-button-add-dmi-quirk-for-medion-akoya-e2228t.patch @@ -0,0 +1,60 @@ +From 51135a4a413ef6ca904a051718c7f0b4dd62055a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 7 Nov 2020 14:32:54 +0100 +Subject: ACPI: button: Add DMI quirk for Medion Akoya E2228T + +From: Hans de Goede + +[ 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 +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + 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 f43f5adc21b61..abf101451c929 100644 +--- a/drivers/acpi/button.c ++++ b/drivers/acpi/button.c +@@ -98,7 +98,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 + diff --git a/queue-4.19/arm64-psci-avoid-printing-in-cpu_psci_cpu_die.patch b/queue-4.19/arm64-psci-avoid-printing-in-cpu_psci_cpu_die.patch new file mode 100644 index 00000000000..98f7ef64015 --- /dev/null +++ b/queue-4.19/arm64-psci-avoid-printing-in-cpu_psci_cpu_die.patch @@ -0,0 +1,50 @@ +From c54efa63e0bcd19408b41777ff3cb980cb7f8595 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Nov 2020 09:57:55 +0000 +Subject: arm64: psci: Avoid printing in cpu_psci_cpu_die() + +From: Will Deacon + +[ 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 +Cc: "Paul E. McKenney" +Cc: Catalin Marinas +Link: https://lore.kernel.org/r/20201106103602.9849-2-will@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Sasha Levin +--- + 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 3856d51c645b5..3ebb2a56e5f7b 100644 +--- a/arch/arm64/kernel/psci.c ++++ b/arch/arm64/kernel/psci.c +@@ -69,7 +69,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. +@@ -77,9 +76,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 + diff --git a/queue-4.19/pinctrl-rockchip-enable-gpio-pclk-for-rockchip_gpio_.patch b/queue-4.19/pinctrl-rockchip-enable-gpio-pclk-for-rockchip_gpio_.patch new file mode 100644 index 00000000000..72c698168a1 --- /dev/null +++ b/queue-4.19/pinctrl-rockchip-enable-gpio-pclk-for-rockchip_gpio_.patch @@ -0,0 +1,39 @@ +From b060cc7dfb0c6e7227358c8dd77221683d3c65e0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 13 Oct 2020 14:37:30 +0800 +Subject: pinctrl: rockchip: enable gpio pclk for rockchip_gpio_to_irq + +From: Jianqun Xu + +[ 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 +Reviewed-by: Heiko Stuebner +Reviewed-by: Kever Yang +Link: https://lore.kernel.org/r/20201013063731.3618-3-jay.xu@rock-chips.com +Signed-off-by: Linus Walleij +Signed-off-by: Sasha Levin +--- + 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 005df24f5b3f1..4d3b62707524a 100644 +--- a/drivers/pinctrl/pinctrl-rockchip.c ++++ b/drivers/pinctrl/pinctrl-rockchip.c +@@ -2778,7 +2778,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 + diff --git a/queue-4.19/scsi-ufs-fix-unbalanced-scsi_block_reqs_cnt-caused-b.patch b/queue-4.19/scsi-ufs-fix-unbalanced-scsi_block_reqs_cnt-caused-b.patch new file mode 100644 index 00000000000..c93c855005c --- /dev/null +++ b/queue-4.19/scsi-ufs-fix-unbalanced-scsi_block_reqs_cnt-caused-b.patch @@ -0,0 +1,51 @@ +From c1c983ddaca745f98a2f3db1ffba060fa164c6d7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Stanley Chu +Reviewed-by: Bean Huo +Signed-off-by: Can Guo +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + 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 b2cbdd01ab10b..a63119c35fde8 100644 +--- a/drivers/scsi/ufs/ufshcd.c ++++ b/drivers/scsi/ufs/ufshcd.c +@@ -1592,12 +1592,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool async) + * work and to enable clocks. + */ + 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 + diff --git a/queue-4.19/selftests-kvm-fix-the-segment-descriptor-layout-to-m.patch b/queue-4.19/selftests-kvm-fix-the-segment-descriptor-layout-to-m.patch new file mode 100644 index 00000000000..9908b7642d0 --- /dev/null +++ b/queue-4.19/selftests-kvm-fix-the-segment-descriptor-layout-to-m.patch @@ -0,0 +1,60 @@ +From 98cb859f3a31f10d35a3c0071186ddff5816c327 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Alexander Graf +Message-Id: <20201012194716.3950330-2-aaronlewis@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Sasha Levin +--- + tools/testing/selftests/kvm/include/x86.h | 2 +- + tools/testing/selftests/kvm/lib/x86.c | 3 ++- + 2 files changed, 3 insertions(+), 2 deletions(-) + +diff --git a/tools/testing/selftests/kvm/include/x86.h b/tools/testing/selftests/kvm/include/x86.h +index 42c3596815b83..a7667a613bbc7 100644 +--- a/tools/testing/selftests/kvm/include/x86.h ++++ b/tools/testing/selftests/kvm/include/x86.h +@@ -59,7 +59,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.c b/tools/testing/selftests/kvm/lib/x86.c +index 4d35eba73dc97..800fe36064f9a 100644 +--- a/tools/testing/selftests/kvm/lib/x86.c ++++ b/tools/testing/selftests/kvm/lib/x86.c +@@ -449,11 +449,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 + diff --git a/queue-4.19/series b/queue-4.19/series index 6bb33be96fb..aa676f0b718 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -24,3 +24,9 @@ net-mlx5-disable-qos-when-min_rates-on-all-vfs-are-zero.patch 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-psci-avoid-printing-in-cpu_psci_cpu_die.patch +vfs-remove-lockdep-bogosity-in-__sb_start_write.patch diff --git a/queue-4.19/vfs-remove-lockdep-bogosity-in-__sb_start_write.patch b/queue-4.19/vfs-remove-lockdep-bogosity-in-__sb_start_write.patch new file mode 100644 index 00000000000..79bb1910538 --- /dev/null +++ b/queue-4.19/vfs-remove-lockdep-bogosity-in-__sb_start_write.patch @@ -0,0 +1,111 @@ +From f5525d140edbc067e13eb442252949040a45fbfc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 10 Nov 2020 16:49:29 -0800 +Subject: vfs: remove lockdep bogosity in __sb_start_write + +From: Darrick J. Wong + +[ 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 +Reviewed-by: Christoph Hellwig +Reviewed-by: Jan Kara +Signed-off-by: Sasha Levin +--- + fs/super.c | 33 ++++----------------------------- + 1 file changed, 4 insertions(+), 29 deletions(-) + +diff --git a/fs/super.c b/fs/super.c +index f3a8c008e1643..9fb4553c46e63 100644 +--- a/fs/super.c ++++ b/fs/super.c +@@ -1360,36 +1360,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 +