From: Greg Kroah-Hartman Date: Tue, 12 Mar 2019 12:57:31 +0000 (-0700) Subject: 4.14-stable patches X-Git-Tag: v5.0.2~15 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ea6f1de3157cf9ff33c0e4c58d54d9cb17c27841;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: ath9k-avoid-of-no-eeprom-quirks-without-qca-no-eeprom.patch driver-core-postpone-dma-tear-down-until-after-devres-release.patch gfs2-fix-missed-wakeups-in-find_insert_glock.patch --- diff --git a/queue-4.14/ath9k-avoid-of-no-eeprom-quirks-without-qca-no-eeprom.patch b/queue-4.14/ath9k-avoid-of-no-eeprom-quirks-without-qca-no-eeprom.patch new file mode 100644 index 00000000000..9e26ad3fe58 --- /dev/null +++ b/queue-4.14/ath9k-avoid-of-no-eeprom-quirks-without-qca-no-eeprom.patch @@ -0,0 +1,88 @@ +From ce938231bd3b1d7af3cbd8836f084801090470e1 Mon Sep 17 00:00:00 2001 +From: "Daniel F. Dickinson" +Date: Sat, 22 Dec 2018 01:09:13 -0500 +Subject: ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom + +From: Daniel F. Dickinson + +commit ce938231bd3b1d7af3cbd8836f084801090470e1 upstream. + +ath9k_of_init() function[0] was initially written on the assumption that +if someone had an explicit ath9k OF node that "there must be something +wrong, why would someone add an OF node if everything is fine"[1] +(Quoting Martin Blumenstingl ) + +"it turns out it's not that simple. with your requirements I'm now aware +of two use-cases where the current code in ath9k_of_init() doesn't work +without modifications"[1] + +The "your requirements" Martin speaks of is the result of the fact that I +have a device (PowerCloud Systems CR5000) has some kind of default - not +unique mac address - set and requires to set the correct MAC address via +mac-address devicetree property, however: + +"some cards come with a physical EEPROM chip [or OTP] so "qca,no-eeprom" +should not be set (your use-case). in this case AH_USE_EEPROM should be +set (which is the default when there is no OF node)"[1] + +The other use case is: + +the firmware on some PowerMac G5 seems to add a OF node for the ath9k +card automatically. depending on the EEPROM on the card AH_NO_EEP_SWAP +should be unset (which is the default when there is no OF node). see [3] + +After this patch to ath9k_of_init() the new behavior will be: + + if there's no OF node then everything is the same as before + if there's an empty OF node then ath9k will use the hardware EEPROM + (before ath9k would fail to initialize because no EEPROM data was + provided by userspace) + if there's an OF node with only a MAC address then ath9k will use + the MAC address and the hardware EEPROM (see the case above) + with "qca,no-eeprom" EEPROM data from userspace will be requested. + the behavior here will not change +[1] + +Martin provides additional background on EEPROM swapping[1]. + +Thanks to Christian Lamparter for all his help on +troubleshooting this issue and the basis for this patch. + +[0]https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/net/wireless/ath/ath9k/init.c#L615 +[1]https://github.com/openwrt/openwrt/pull/1645#issuecomment-448027058 +[2]https://github.com/openwrt/openwrt/pull/1613 +[3]https://patchwork.kernel.org/patch/10241731/ + +Fixes: 138b41253d9c ("ath9k: parse the device configuration from an OF node") +Reviewed-by: Martin Blumenstingl +Tested-by: Martin Blumenstingl +Signed-off-by: Daniel F. Dickinson +Signed-off-by: Kalle Valo +Cc: Christian Lamparter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath/ath9k/init.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/net/wireless/ath/ath9k/init.c ++++ b/drivers/net/wireless/ath/ath9k/init.c +@@ -580,15 +580,15 @@ static int ath9k_of_init(struct ath_soft + ret = ath9k_eeprom_request(sc, eeprom_name); + if (ret) + return ret; ++ ++ ah->ah_flags &= ~AH_USE_EEPROM; ++ ah->ah_flags |= AH_NO_EEP_SWAP; + } + + mac = of_get_mac_address(np); + if (mac) + ether_addr_copy(common->macaddr, mac); + +- ah->ah_flags &= ~AH_USE_EEPROM; +- ah->ah_flags |= AH_NO_EEP_SWAP; +- + return 0; + } + diff --git a/queue-4.14/driver-core-postpone-dma-tear-down-until-after-devres-release.patch b/queue-4.14/driver-core-postpone-dma-tear-down-until-after-devres-release.patch new file mode 100644 index 00000000000..ffbb84815d7 --- /dev/null +++ b/queue-4.14/driver-core-postpone-dma-tear-down-until-after-devres-release.patch @@ -0,0 +1,119 @@ +From 376991db4b6464e906d699ef07681e2ffa8ab08c Mon Sep 17 00:00:00 2001 +From: Geert Uytterhoeven +Date: Thu, 7 Feb 2019 20:36:53 +0100 +Subject: driver core: Postpone DMA tear-down until after devres release +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Geert Uytterhoeven + +commit 376991db4b6464e906d699ef07681e2ffa8ab08c upstream. + +When unbinding the (IOMMU-enabled) R-Car SATA device on Salvator-XS +(R-Car H3 ES2.0), in preparation of rebinding against vfio-platform for +device pass-through for virtualization: + +    echo ee300000.sata > /sys/bus/platform/drivers/sata_rcar/unbind + +the kernel crashes with: + +    Unable to handle kernel paging request at virtual address ffffffbf029ffffc +    Mem abort info: +      ESR = 0x96000006 +      Exception class = DABT (current EL), IL = 32 bits +      SET = 0, FnV = 0 +      EA = 0, S1PTW = 0 +    Data abort info: +      ISV = 0, ISS = 0x00000006 +      CM = 0, WnR = 0 +    swapper pgtable: 4k pages, 39-bit VAs, pgdp = 000000007e8c586c +    [ffffffbf029ffffc] pgd=000000073bfc6003, pud=000000073bfc6003, pmd=0000000000000000 +    Internal error: Oops: 96000006 [#1] SMP +    Modules linked in: +    CPU: 0 PID: 1098 Comm: bash Not tainted 5.0.0-rc5-salvator-x-00452-g37596f884f4318ef #287 +    Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT) +    pstate: 60400005 (nZCv daif +PAN -UAO) +    pc : __free_pages+0x8/0x58 +    lr : __dma_direct_free_pages+0x50/0x5c +    sp : ffffff801268baa0 +    x29: ffffff801268baa0 x28: 0000000000000000 +    x27: ffffffc6f9c60bf0 x26: ffffffc6f9c60bf0 +    x25: ffffffc6f9c60810 x24: 0000000000000000 +    x23: 00000000fffff000 x22: ffffff8012145000 +    x21: 0000000000000800 x20: ffffffbf029fffc8 +    x19: 0000000000000000 x18: ffffffc6f86c42c8 +    x17: 0000000000000000 x16: 0000000000000070 +    x15: 0000000000000003 x14: 0000000000000000 +    x13: ffffff801103d7f8 x12: 0000000000000028 +    x11: ffffff8011117604 x10: 0000000000009ad8 +    x9 : ffffff80110126d0 x8 : ffffffc6f7563000 +    x7 : 6b6b6b6b6b6b6b6b x6 : 0000000000000018 +    x5 : ffffff8011cf3cc8 x4 : 0000000000004000 +    x3 : 0000000000080000 x2 : 0000000000000001 +    x1 : 0000000000000000 x0 : ffffffbf029fffc8 +    Process bash (pid: 1098, stack limit = 0x00000000c38e3e32) +    Call trace: +     __free_pages+0x8/0x58 +     __dma_direct_free_pages+0x50/0x5c +     arch_dma_free+0x1c/0x98 +     dma_direct_free+0x14/0x24 +     dma_free_attrs+0x9c/0xdc +     dmam_release+0x18/0x20 +     release_nodes+0x25c/0x28c +     devres_release_all+0x48/0x4c +     device_release_driver_internal+0x184/0x1f0 +     device_release_driver+0x14/0x1c +     unbind_store+0x70/0xb8 +     drv_attr_store+0x24/0x34 +     sysfs_kf_write+0x4c/0x64 +     kernfs_fop_write+0x154/0x1c4 +     __vfs_write+0x34/0x164 +     vfs_write+0xb4/0x16c +     ksys_write+0x5c/0xbc +     __arm64_sys_write+0x14/0x1c +     el0_svc_common+0x98/0x114 +     el0_svc_handler+0x1c/0x24 +     el0_svc+0x8/0xc +    Code: d51b4234 17fffffa a9bf7bfd 910003fd (b9403404) +    ---[ end trace 8c564cdd3a1a840f ]--- + +While I've bisected this to commit e8e683ae9a736407 ("iommu/of: Fix +probe-deferral"), and reverting that commit on post-v5.0-rc4 kernels +does fix the problem, this turned out to be a red herring. + +On arm64, arch_teardown_dma_ops() resets dev->dma_ops to NULL. +Hence if a driver has used a managed DMA allocation API, the allocated +DMA memory will be freed using the direct DMA ops, while it may have +been allocated using a custom DMA ops (iommu_dma_ops in this case). + +Fix this by reversing the order of the calls to devres_release_all() and +arch_teardown_dma_ops(). + +Signed-off-by: Geert Uytterhoeven +Acked-by: Christoph Hellwig +Reviewed-by: Rafael J. Wysocki +Cc: stable +Reviewed-by: Robin Murphy +[rm: backport for 4.12-4.19 - kernels before 5.0 will not see + the crash above, but may get silent memory corruption instead] +Signed-off-by: Robin Murphy +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/base/dd.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/base/dd.c ++++ b/drivers/base/dd.c +@@ -850,9 +850,9 @@ static void __device_release_driver(stru + drv->remove(dev); + + device_links_driver_cleanup(dev); +- dma_deconfigure(dev); + + devres_release_all(dev); ++ dma_deconfigure(dev); + dev->driver = NULL; + dev_set_drvdata(dev, NULL); + if (dev->pm_domain && dev->pm_domain->dismiss) diff --git a/queue-4.14/gfs2-fix-missed-wakeups-in-find_insert_glock.patch b/queue-4.14/gfs2-fix-missed-wakeups-in-find_insert_glock.patch new file mode 100644 index 00000000000..29404caa7fe --- /dev/null +++ b/queue-4.14/gfs2-fix-missed-wakeups-in-find_insert_glock.patch @@ -0,0 +1,38 @@ +From 605b0487f0bc1ae9963bf52ece0f5c8055186f81 Mon Sep 17 00:00:00 2001 +From: Andreas Gruenbacher +Date: Wed, 6 Mar 2019 15:41:57 +0100 +Subject: gfs2: Fix missed wakeups in find_insert_glock + +From: Andreas Gruenbacher + +commit 605b0487f0bc1ae9963bf52ece0f5c8055186f81 upstream. + +Mark Syms has reported seeing tasks that are stuck waiting in +find_insert_glock. It turns out that struct lm_lockname contains four padding +bytes on 64-bit architectures that function glock_waitqueue doesn't skip when +hashing the glock name. As a result, we can end up waking up the wrong +waitqueue, and the waiting tasks may be stuck forever. + +Fix that by using ht_parms.key_len instead of sizeof(struct lm_lockname) for +the key length. + +Reported-by: Mark Syms +Signed-off-by: Andreas Gruenbacher +Signed-off-by: Bob Peterson +Signed-off-by: Greg Kroah-Hartman + +--- + fs/gfs2/glock.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/gfs2/glock.c ++++ b/fs/gfs2/glock.c +@@ -107,7 +107,7 @@ static int glock_wake_function(wait_queu + + static wait_queue_head_t *glock_waitqueue(struct lm_lockname *name) + { +- u32 hash = jhash2((u32 *)name, sizeof(*name) / 4, 0); ++ u32 hash = jhash2((u32 *)name, ht_parms.key_len / 4, 0); + + return glock_wait_table + hash_32(hash, GLOCK_WAIT_TABLE_BITS); + } diff --git a/queue-4.14/series b/queue-4.14/series index 9f67f29245d..5c62e582e36 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -126,3 +126,6 @@ arm-dts-exynos-fix-pinctrl-definition-for-emmc-rtsn-line-on-odroid-x2-u3.patch arm-dts-exynos-add-minimal-clkout-parameters-to-exynos3250-pmu.patch drm-disable-uncached-dma-optimization-for-arm-and-ar.patch arm-8781-1-fix-thumb-2-syscall-return-for-binutils-2.patch +gfs2-fix-missed-wakeups-in-find_insert_glock.patch +ath9k-avoid-of-no-eeprom-quirks-without-qca-no-eeprom.patch +driver-core-postpone-dma-tear-down-until-after-devres-release.patch