From: Greg Kroah-Hartman Date: Mon, 15 Apr 2019 16:41:44 +0000 (+0200) Subject: 4.4-stable patches X-Git-Tag: v4.9.169~12 X-Git-Url: http://git.ipfire.org/?p=thirdparty%2Fkernel%2Fstable-queue.git;a=commitdiff_plain;h=3762281c89f86bf794e392cabeac0dedefce598e 4.4-stable patches added patches: arm-dts-at91-fix-typo-in-isc_d0-on-pc9.patch arm64-futex-fix-futex_wake_op-atomic-ops-with-non-zero-result-value.patch dm-table-propagate-bdi_cap_stable_writes-to-fix-sporadic-checksum-errors.patch pci-add-function-1-dma-alias-quirk-for-marvell-9170-sata-controller.patch sched-fair-do-not-re-read-h_load_next-during-hierarchical-load-calculation.patch xen-prevent-buffer-overflow-in-privcmd-ioctl.patch xtensa-fix-return_address.patch --- diff --git a/queue-4.4/arm-dts-at91-fix-typo-in-isc_d0-on-pc9.patch b/queue-4.4/arm-dts-at91-fix-typo-in-isc_d0-on-pc9.patch new file mode 100644 index 0000000000..40b7ffb4ae --- /dev/null +++ b/queue-4.4/arm-dts-at91-fix-typo-in-isc_d0-on-pc9.patch @@ -0,0 +1,34 @@ +From e7dfb6d04e4715be1f3eb2c60d97b753fd2e4516 Mon Sep 17 00:00:00 2001 +From: David Engraf +Date: Mon, 11 Mar 2019 08:57:42 +0100 +Subject: ARM: dts: at91: Fix typo in ISC_D0 on PC9 + +From: David Engraf + +commit e7dfb6d04e4715be1f3eb2c60d97b753fd2e4516 upstream. + +The function argument for the ISC_D0 on PC9 was incorrect. According to +the documentation it should be 'C' aka 3. + +Signed-off-by: David Engraf +Reviewed-by: Nicolas Ferre +Signed-off-by: Ludovic Desroches +Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux") +Cc: # v4.4+ +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/boot/dts/sama5d2-pinfunc.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/boot/dts/sama5d2-pinfunc.h ++++ b/arch/arm/boot/dts/sama5d2-pinfunc.h +@@ -517,7 +517,7 @@ + #define PIN_PC9__GPIO PINMUX_PIN(PIN_PC9, 0, 0) + #define PIN_PC9__FIQ PINMUX_PIN(PIN_PC9, 1, 3) + #define PIN_PC9__GTSUCOMP PINMUX_PIN(PIN_PC9, 2, 1) +-#define PIN_PC9__ISC_D0 PINMUX_PIN(PIN_PC9, 2, 1) ++#define PIN_PC9__ISC_D0 PINMUX_PIN(PIN_PC9, 3, 1) + #define PIN_PC9__TIOA4 PINMUX_PIN(PIN_PC9, 4, 2) + #define PIN_PC10 74 + #define PIN_PC10__GPIO PINMUX_PIN(PIN_PC10, 0, 0) diff --git a/queue-4.4/arm64-futex-fix-futex_wake_op-atomic-ops-with-non-zero-result-value.patch b/queue-4.4/arm64-futex-fix-futex_wake_op-atomic-ops-with-non-zero-result-value.patch new file mode 100644 index 0000000000..ef68c06135 --- /dev/null +++ b/queue-4.4/arm64-futex-fix-futex_wake_op-atomic-ops-with-non-zero-result-value.patch @@ -0,0 +1,91 @@ +From 045afc24124d80c6998d9c770844c67912083506 Mon Sep 17 00:00:00 2001 +From: Will Deacon +Date: Mon, 8 Apr 2019 12:45:09 +0100 +Subject: arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value + +From: Will Deacon + +commit 045afc24124d80c6998d9c770844c67912083506 upstream. + +Rather embarrassingly, our futex() FUTEX_WAKE_OP implementation doesn't +explicitly set the return value on the non-faulting path and instead +leaves it holding the result of the underlying atomic operation. This +means that any FUTEX_WAKE_OP atomic operation which computes a non-zero +value will be reported as having failed. Regrettably, I wrote the buggy +code back in 2011 and it was upstreamed as part of the initial arm64 +support in 2012. + +The reasons we appear to get away with this are: + + 1. FUTEX_WAKE_OP is rarely used and therefore doesn't appear to get + exercised by futex() test applications + + 2. If the result of the atomic operation is zero, the system call + behaves correctly + + 3. Prior to version 2.25, the only operation used by GLIBC set the + futex to zero, and therefore worked as expected. From 2.25 onwards, + FUTEX_WAKE_OP is not used by GLIBC at all. + +Fix the implementation by ensuring that the return value is either 0 +to indicate that the atomic operation completed successfully, or -EFAULT +if we encountered a fault when accessing the user mapping. + +Cc: +Fixes: 6170a97460db ("arm64: Atomic operations") +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/include/asm/futex.h | 16 ++++++++-------- + 1 file changed, 8 insertions(+), 8 deletions(-) + +--- a/arch/arm64/include/asm/futex.h ++++ b/arch/arm64/include/asm/futex.h +@@ -33,8 +33,8 @@ + " prfm pstl1strm, %2\n" \ + "1: ldxr %w1, %2\n" \ + insn "\n" \ +-"2: stlxr %w3, %w0, %2\n" \ +-" cbnz %w3, 1b\n" \ ++"2: stlxr %w0, %w3, %2\n" \ ++" cbnz %w0, 1b\n" \ + " dmb ish\n" \ + "3:\n" \ + " .pushsection .fixup,\"ax\"\n" \ +@@ -55,29 +55,29 @@ + static inline int + arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr) + { +- int oldval = 0, ret, tmp; ++ int oldval, ret, tmp; + + pagefault_disable(); + + switch (op) { + case FUTEX_OP_SET: +- __futex_atomic_op("mov %w0, %w4", ++ __futex_atomic_op("mov %w3, %w4", + ret, oldval, uaddr, tmp, oparg); + break; + case FUTEX_OP_ADD: +- __futex_atomic_op("add %w0, %w1, %w4", ++ __futex_atomic_op("add %w3, %w1, %w4", + ret, oldval, uaddr, tmp, oparg); + break; + case FUTEX_OP_OR: +- __futex_atomic_op("orr %w0, %w1, %w4", ++ __futex_atomic_op("orr %w3, %w1, %w4", + ret, oldval, uaddr, tmp, oparg); + break; + case FUTEX_OP_ANDN: +- __futex_atomic_op("and %w0, %w1, %w4", ++ __futex_atomic_op("and %w3, %w1, %w4", + ret, oldval, uaddr, tmp, ~oparg); + break; + case FUTEX_OP_XOR: +- __futex_atomic_op("eor %w0, %w1, %w4", ++ __futex_atomic_op("eor %w3, %w1, %w4", + ret, oldval, uaddr, tmp, oparg); + break; + default: diff --git a/queue-4.4/dm-table-propagate-bdi_cap_stable_writes-to-fix-sporadic-checksum-errors.patch b/queue-4.4/dm-table-propagate-bdi_cap_stable_writes-to-fix-sporadic-checksum-errors.patch new file mode 100644 index 0000000000..6b7ee07661 --- /dev/null +++ b/queue-4.4/dm-table-propagate-bdi_cap_stable_writes-to-fix-sporadic-checksum-errors.patch @@ -0,0 +1,80 @@ +From eb40c0acdc342b815d4d03ae6abb09e80c0f2988 Mon Sep 17 00:00:00 2001 +From: Ilya Dryomov +Date: Tue, 26 Mar 2019 20:20:58 +0100 +Subject: dm table: propagate BDI_CAP_STABLE_WRITES to fix sporadic checksum errors + +From: Ilya Dryomov + +commit eb40c0acdc342b815d4d03ae6abb09e80c0f2988 upstream. + +Some devices don't use blk_integrity but still want stable pages +because they do their own checksumming. Examples include rbd and iSCSI +when data digests are negotiated. Stacking DM (and thus LVM) on top of +these devices results in sporadic checksum errors. + +Set BDI_CAP_STABLE_WRITES if any underlying device has it set. + +Cc: stable@vger.kernel.org +Signed-off-by: Ilya Dryomov +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/dm-table.c | 39 +++++++++++++++++++++++++++++++++++++++ + 1 file changed, 39 insertions(+) + +--- a/drivers/md/dm-table.c ++++ b/drivers/md/dm-table.c +@@ -1479,6 +1479,36 @@ static bool dm_table_supports_discards(s + return false; + } + ++static int device_requires_stable_pages(struct dm_target *ti, ++ struct dm_dev *dev, sector_t start, ++ sector_t len, void *data) ++{ ++ struct request_queue *q = bdev_get_queue(dev->bdev); ++ ++ return q && bdi_cap_stable_pages_required(q->backing_dev_info); ++} ++ ++/* ++ * If any underlying device requires stable pages, a table must require ++ * them as well. Only targets that support iterate_devices are considered: ++ * don't want error, zero, etc to require stable pages. ++ */ ++static bool dm_table_requires_stable_pages(struct dm_table *t) ++{ ++ struct dm_target *ti; ++ unsigned i; ++ ++ for (i = 0; i < dm_table_get_num_targets(t); i++) { ++ ti = dm_table_get_target(t, i); ++ ++ if (ti->type->iterate_devices && ++ ti->type->iterate_devices(ti, device_requires_stable_pages, NULL)) ++ return true; ++ } ++ ++ return false; ++} ++ + void dm_table_set_restrictions(struct dm_table *t, struct request_queue *q, + struct queue_limits *limits) + { +@@ -1521,6 +1551,15 @@ void dm_table_set_restrictions(struct dm + dm_table_verify_integrity(t); + + /* ++ * Some devices don't use blk_integrity but still want stable pages ++ * because they do their own checksumming. ++ */ ++ if (dm_table_requires_stable_pages(t)) ++ q->backing_dev_info->capabilities |= BDI_CAP_STABLE_WRITES; ++ else ++ q->backing_dev_info->capabilities &= ~BDI_CAP_STABLE_WRITES; ++ ++ /* + * Determine whether or not this queue's I/O timings contribute + * to the entropy pool, Only request-based targets use this. + * Clear QUEUE_FLAG_ADD_RANDOM if any underlying device does not diff --git a/queue-4.4/pci-add-function-1-dma-alias-quirk-for-marvell-9170-sata-controller.patch b/queue-4.4/pci-add-function-1-dma-alias-quirk-for-marvell-9170-sata-controller.patch new file mode 100644 index 0000000000..50a4f0d462 --- /dev/null +++ b/queue-4.4/pci-add-function-1-dma-alias-quirk-for-marvell-9170-sata-controller.patch @@ -0,0 +1,37 @@ +From 9cde402a59770a0669d895399c13407f63d7d209 Mon Sep 17 00:00:00 2001 +From: Andre Przywara +Date: Fri, 5 Apr 2019 16:20:47 +0100 +Subject: PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller + +From: Andre Przywara + +commit 9cde402a59770a0669d895399c13407f63d7d209 upstream. + +There is a Marvell 88SE9170 PCIe SATA controller I found on a board here. +Some quick testing with the ARM SMMU enabled reveals that it suffers from +the same requester ID mixup problems as the other Marvell chips listed +already. + +Add the PCI vendor/device ID to the list of chips which need the +workaround. + +Signed-off-by: Andre Przywara +Signed-off-by: Bjorn Helgaas +CC: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/quirks.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -3623,6 +3623,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M + /* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c14 */ + DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9130, + quirk_dma_func1_alias); ++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9170, ++ quirk_dma_func1_alias); + /* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c47 + c57 */ + DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9172, + quirk_dma_func1_alias); diff --git a/queue-4.4/sched-fair-do-not-re-read-h_load_next-during-hierarchical-load-calculation.patch b/queue-4.4/sched-fair-do-not-re-read-h_load_next-during-hierarchical-load-calculation.patch new file mode 100644 index 0000000000..c769ff9ddf --- /dev/null +++ b/queue-4.4/sched-fair-do-not-re-read-h_load_next-during-hierarchical-load-calculation.patch @@ -0,0 +1,82 @@ +From 0e9f02450da07fc7b1346c8c32c771555173e397 Mon Sep 17 00:00:00 2001 +From: Mel Gorman +Date: Tue, 19 Mar 2019 12:36:10 +0000 +Subject: sched/fair: Do not re-read ->h_load_next during hierarchical load calculation + +From: Mel Gorman + +commit 0e9f02450da07fc7b1346c8c32c771555173e397 upstream. + +A NULL pointer dereference bug was reported on a distribution kernel but +the same issue should be present on mainline kernel. It occured on s390 +but should not be arch-specific. A partial oops looks like: + + Unable to handle kernel pointer dereference in virtual kernel address space + ... + Call Trace: + ... + try_to_wake_up+0xfc/0x450 + vhost_poll_wakeup+0x3a/0x50 [vhost] + __wake_up_common+0xbc/0x178 + __wake_up_common_lock+0x9e/0x160 + __wake_up_sync_key+0x4e/0x60 + sock_def_readable+0x5e/0x98 + +The bug hits any time between 1 hour to 3 days. The dereference occurs +in update_cfs_rq_h_load when accumulating h_load. The problem is that +cfq_rq->h_load_next is not protected by any locking and can be updated +by parallel calls to task_h_load. Depending on the compiler, code may be +generated that re-reads cfq_rq->h_load_next after the check for NULL and +then oops when reading se->avg.load_avg. The dissassembly showed that it +was possible to reread h_load_next after the check for NULL. + +While this does not appear to be an issue for later compilers, it's still +an accident if the correct code is generated. Full locking in this path +would have high overhead so this patch uses READ_ONCE to read h_load_next +only once and check for NULL before dereferencing. It was confirmed that +there were no further oops after 10 days of testing. + +As Peter pointed out, it is also necessary to use WRITE_ONCE() to avoid any +potential problems with store tearing. + +Signed-off-by: Mel Gorman +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Valentin Schneider +Cc: Linus Torvalds +Cc: Mike Galbraith +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: +Fixes: 685207963be9 ("sched: Move h_load calculation to task_h_load()") +Link: https://lkml.kernel.org/r/20190319123610.nsivgf3mjbjjesxb@techsingularity.net +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/sched/fair.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/kernel/sched/fair.c ++++ b/kernel/sched/fair.c +@@ -6022,10 +6022,10 @@ static void update_cfs_rq_h_load(struct + if (cfs_rq->last_h_load_update == now) + return; + +- cfs_rq->h_load_next = NULL; ++ WRITE_ONCE(cfs_rq->h_load_next, NULL); + for_each_sched_entity(se) { + cfs_rq = cfs_rq_of(se); +- cfs_rq->h_load_next = se; ++ WRITE_ONCE(cfs_rq->h_load_next, se); + if (cfs_rq->last_h_load_update == now) + break; + } +@@ -6035,7 +6035,7 @@ static void update_cfs_rq_h_load(struct + cfs_rq->last_h_load_update = now; + } + +- while ((se = cfs_rq->h_load_next) != NULL) { ++ while ((se = READ_ONCE(cfs_rq->h_load_next)) != NULL) { + load = cfs_rq->h_load; + load = div64_ul(load * se->avg.load_avg, + cfs_rq_load_avg(cfs_rq) + 1); diff --git a/queue-4.4/series b/queue-4.4/series index 1135fa2e2d..b6f3c54034 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -89,3 +89,10 @@ include-linux-bitrev.h-fix-constant-bitrev.patch asoc-fsl_esai-fix-channel-swap-issue-when-stream-starts.patch block-do-not-leak-memory-in-bio_copy_user_iov.patch genirq-respect-irqchip_skip_set_wake-in-irq_chip_set_wake_parent.patch +arm-dts-at91-fix-typo-in-isc_d0-on-pc9.patch +arm64-futex-fix-futex_wake_op-atomic-ops-with-non-zero-result-value.patch +xen-prevent-buffer-overflow-in-privcmd-ioctl.patch +sched-fair-do-not-re-read-h_load_next-during-hierarchical-load-calculation.patch +xtensa-fix-return_address.patch +pci-add-function-1-dma-alias-quirk-for-marvell-9170-sata-controller.patch +dm-table-propagate-bdi_cap_stable_writes-to-fix-sporadic-checksum-errors.patch diff --git a/queue-4.4/xen-prevent-buffer-overflow-in-privcmd-ioctl.patch b/queue-4.4/xen-prevent-buffer-overflow-in-privcmd-ioctl.patch new file mode 100644 index 0000000000..6a881f50ee --- /dev/null +++ b/queue-4.4/xen-prevent-buffer-overflow-in-privcmd-ioctl.patch @@ -0,0 +1,37 @@ +From 42d8644bd77dd2d747e004e367cb0c895a606f39 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Thu, 4 Apr 2019 18:12:17 +0300 +Subject: xen: Prevent buffer overflow in privcmd ioctl + +From: Dan Carpenter + +commit 42d8644bd77dd2d747e004e367cb0c895a606f39 upstream. + +The "call" variable comes from the user in privcmd_ioctl_hypercall(). +It's an offset into the hypercall_page[] which has (PAGE_SIZE / 32) +elements. We need to put an upper bound on it to prevent an out of +bounds access. + +Cc: stable@vger.kernel.org +Fixes: 1246ae0bb992 ("xen: add variable hypercall caller") +Signed-off-by: Dan Carpenter +Reviewed-by: Boris Ostrovsky +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/xen/hypercall.h | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/x86/include/asm/xen/hypercall.h ++++ b/arch/x86/include/asm/xen/hypercall.h +@@ -215,6 +215,9 @@ privcmd_call(unsigned call, + __HYPERCALL_DECLS; + __HYPERCALL_5ARG(a1, a2, a3, a4, a5); + ++ if (call >= PAGE_SIZE / sizeof(hypercall_page[0])) ++ return -EINVAL; ++ + stac(); + asm volatile(CALL_NOSPEC + : __HYPERCALL_5PARAM diff --git a/queue-4.4/xtensa-fix-return_address.patch b/queue-4.4/xtensa-fix-return_address.patch new file mode 100644 index 0000000000..fb43790da2 --- /dev/null +++ b/queue-4.4/xtensa-fix-return_address.patch @@ -0,0 +1,42 @@ +From ada770b1e74a77fff2d5f539bf6c42c25f4784db Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Thu, 4 Apr 2019 11:08:40 -0700 +Subject: xtensa: fix return_address + +From: Max Filippov + +commit ada770b1e74a77fff2d5f539bf6c42c25f4784db upstream. + +return_address returns the address that is one level higher in the call +stack than requested in its argument, because level 0 corresponds to its +caller's return address. Use requested level as the number of stack +frames to skip. + +This fixes the address reported by might_sleep and friends. + +Cc: stable@vger.kernel.org +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman + +--- + arch/xtensa/kernel/stacktrace.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/xtensa/kernel/stacktrace.c ++++ b/arch/xtensa/kernel/stacktrace.c +@@ -272,10 +272,14 @@ static int return_address_cb(struct stac + return 1; + } + ++/* ++ * level == 0 is for the return address from the caller of this function, ++ * not from this function itself. ++ */ + unsigned long return_address(unsigned level) + { + struct return_addr_data r = { +- .skip = level + 1, ++ .skip = level, + }; + walk_stackframe(stack_pointer(NULL), return_address_cb, &r); + return r.addr;