--- /dev/null
+From e7dfb6d04e4715be1f3eb2c60d97b753fd2e4516 Mon Sep 17 00:00:00 2001
+From: David Engraf <david.engraf@sysgo.com>
+Date: Mon, 11 Mar 2019 08:57:42 +0100
+Subject: ARM: dts: at91: Fix typo in ISC_D0 on PC9
+
+From: David Engraf <david.engraf@sysgo.com>
+
+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 <david.engraf@sysgo.com>
+Reviewed-by: Nicolas Ferre <nicolas.ferre@microchip.com>
+Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
+Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux")
+Cc: <stable@vger.kernel.org> # v4.4+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 045afc24124d80c6998d9c770844c67912083506 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will.deacon@arm.com>
+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 <will.deacon@arm.com>
+
+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: <stable@kernel.org>
+Fixes: 6170a97460db ("arm64: Atomic operations")
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From eb40c0acdc342b815d4d03ae6abb09e80c0f2988 Mon Sep 17 00:00:00 2001
+From: Ilya Dryomov <idryomov@gmail.com>
+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 <idryomov@gmail.com>
+
+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 <idryomov@gmail.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 9cde402a59770a0669d895399c13407f63d7d209 Mon Sep 17 00:00:00 2001
+From: Andre Przywara <andre.przywara@arm.com>
+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 <andre.przywara@arm.com>
+
+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 <andre.przywara@arm.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+CC: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 0e9f02450da07fc7b1346c8c32c771555173e397 Mon Sep 17 00:00:00 2001
+From: Mel Gorman <mgorman@techsingularity.net>
+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 <mgorman@techsingularity.net>
+
+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 <mgorman@techsingularity.net>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Mike Galbraith <efault@gmx.de>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: <stable@vger.kernel.org>
+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 <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
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
--- /dev/null
+From 42d8644bd77dd2d747e004e367cb0c895a606f39 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Thu, 4 Apr 2019 18:12:17 +0300
+Subject: xen: Prevent buffer overflow in privcmd ioctl
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+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 <dan.carpenter@oracle.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From ada770b1e74a77fff2d5f539bf6c42c25f4784db Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Thu, 4 Apr 2019 11:08:40 -0700
+Subject: xtensa: fix return_address
+
+From: Max Filippov <jcmvbkbc@gmail.com>
+
+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 <jcmvbkbc@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
