--- /dev/null
+From cabe5f85e63626c00f3b879a670ec27325056a2d Mon Sep 17 00:00:00 2001
+From: Adam Ford <aford173@gmail.com>
+Date: Wed, 16 Oct 2019 09:40:05 -0500
+Subject: ARM: dts: imx6-logicpd: Re-enable SNVS power key
+
+From: Adam Ford <aford173@gmail.com>
+
+commit cabe5f85e63626c00f3b879a670ec27325056a2d upstream.
+
+The baseboard of the Logic PD i.MX6 development kit has a power
+button routed which can both power down and power up the board.
+It can also wake the board from sleep. This functionality was
+marked as disabled by default in imx6qdl.dtsi, so it needs to
+be explicitly enabled for each board.
+
+This patch enables the snvs power key again.
+
+Signed-off-by: Adam Ford <aford173@gmail.com>
+Fixes: 770856f0da5d ("ARM: dts: imx6qdl: Enable SNVS power key according to board design")
+Cc: stable <stable@vger.kernel.org> #5.3+
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi
++++ b/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi
+@@ -328,6 +328,10 @@
+ pinctrl-0 = <&pinctrl_pwm3>;
+ };
+
++&snvs_pwrkey {
++ status = "okay";
++};
++
+ &ssi2 {
+ status = "okay";
+ };
--- /dev/null
+From e690053e97e7a9c968df9a97cef9089dfa8e6a44 Mon Sep 17 00:00:00 2001
+From: Ondrej Jirman <megous@megous.com>
+Date: Mon, 28 Oct 2019 22:49:14 +0100
+Subject: ARM: sunxi: Fix CPU powerdown on A83T
+
+From: Ondrej Jirman <megous@megous.com>
+
+commit e690053e97e7a9c968df9a97cef9089dfa8e6a44 upstream.
+
+PRCM_PWROFF_GATING_REG has CPU0 at bit 4 on A83T. So without this
+patch, instead of gating the CPU0, the whole cluster was power gated,
+when shutting down first CPU in the cluster.
+
+Fixes: 6961275e72a8c1 ("ARM: sun8i: smp: Add support for A83T")
+Signed-off-by: Ondrej Jirman <megous@megous.com>
+Acked-by: Chen-Yu Tsai <wens@csie.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Maxime Ripard <mripard@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-sunxi/mc_smp.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/mach-sunxi/mc_smp.c
++++ b/arch/arm/mach-sunxi/mc_smp.c
+@@ -481,14 +481,18 @@ static void sunxi_mc_smp_cpu_die(unsigne
+ static int sunxi_cpu_powerdown(unsigned int cpu, unsigned int cluster)
+ {
+ u32 reg;
++ int gating_bit = cpu;
+
+ pr_debug("%s: cluster %u cpu %u\n", __func__, cluster, cpu);
+ if (cpu >= SUNXI_CPUS_PER_CLUSTER || cluster >= SUNXI_NR_CLUSTERS)
+ return -EINVAL;
+
++ if (is_a83t && cpu == 0)
++ gating_bit = 4;
++
+ /* gate processor power */
+ reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
+- reg |= PRCM_PWROFF_GATING_REG_CORE(cpu);
++ reg |= PRCM_PWROFF_GATING_REG_CORE(gating_bit);
+ writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
+ udelay(20);
+
--- /dev/null
+From 6767df245f4736d0cf0c6fb7cf9cf94b27414245 Mon Sep 17 00:00:00 2001
+From: Catalin Marinas <catalin.marinas@arm.com>
+Date: Wed, 6 Nov 2019 15:41:05 +0000
+Subject: arm64: Do not mask out PTE_RDONLY in pte_same()
+
+From: Catalin Marinas <catalin.marinas@arm.com>
+
+commit 6767df245f4736d0cf0c6fb7cf9cf94b27414245 upstream.
+
+Following commit 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out
+of set_pte_at()"), the PTE_RDONLY bit is no longer managed by
+set_pte_at() but built into the PAGE_* attribute definitions.
+Consequently, pte_same() must include this bit when checking two PTEs
+for equality.
+
+Remove the arm64-specific pte_same() function, practically reverting
+commit 747a70e60b72 ("arm64: Fix copy-on-write referencing in HugeTLB")
+
+Fixes: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()")
+Cc: <stable@vger.kernel.org> # 4.14.x-
+Cc: Will Deacon <will@kernel.org>
+Cc: Steve Capper <steve.capper@arm.com>
+Reported-by: John Stultz <john.stultz@linaro.org>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/include/asm/pgtable.h | 17 -----------------
+ 1 file changed, 17 deletions(-)
+
+--- a/arch/arm64/include/asm/pgtable.h
++++ b/arch/arm64/include/asm/pgtable.h
+@@ -283,23 +283,6 @@ static inline void set_pte_at(struct mm_
+ set_pte(ptep, pte);
+ }
+
+-#define __HAVE_ARCH_PTE_SAME
+-static inline int pte_same(pte_t pte_a, pte_t pte_b)
+-{
+- pteval_t lhs, rhs;
+-
+- lhs = pte_val(pte_a);
+- rhs = pte_val(pte_b);
+-
+- if (pte_present(pte_a))
+- lhs &= ~PTE_RDONLY;
+-
+- if (pte_present(pte_b))
+- rhs &= ~PTE_RDONLY;
+-
+- return (lhs == rhs);
+-}
+-
+ /*
+ * Huge pte definitions.
+ */
--- /dev/null
+From d10be65f87fc9d98ad3cbdc406e86745fe8c59e2 Mon Sep 17 00:00:00 2001
+From: Jiada Wang <jiada_wang@mentor.com>
+Date: Tue, 22 Oct 2019 20:54:29 +0200
+Subject: ASoC: rsnd: dma: fix SSI9 4/5/6/7 busif dma address
+
+From: Jiada Wang <jiada_wang@mentor.com>
+
+commit d10be65f87fc9d98ad3cbdc406e86745fe8c59e2 upstream.
+
+Currently each SSI unit's busif dma address is calculated by
+following calculation formula:
+0xec540000 + 0x1000 * id + busif / 4 * 0xA000 + busif % 4 * 0x400
+
+But according to R-Car3 HW manual 41.1.4 Register Configuration,
+ssi9 4/5/6/7 busif data register address
+(SSI9_4_BUSIF/SSI9_5_BUSIF/SSI9_6_BUSIF/SSI9_7_BUSIF)
+are out of this rule.
+
+This patch updates the calculation formula to correct
+ssi9 4/5/6/7 busif data register address.
+
+Fixes: 5e45a6fab3b9 ("ASoc: rsnd: dma: Calculate dma address with consider of BUSIF")
+Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
+Signed-off-by: Timo Wischer <twischer@de.adit-jv.com>
+[erosca: minor improvements in commit description]
+Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com>
+Cc: stable@vger.kernel.org # v4.20+
+Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
+Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+Link: https://lore.kernel.org/r/20191022185429.12769-1-erosca@de.adit-jv.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/sh/rcar/dma.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/sh/rcar/dma.c
++++ b/sound/soc/sh/rcar/dma.c
+@@ -508,10 +508,10 @@ static struct rsnd_mod_ops rsnd_dmapp_op
+ #define RDMA_SSI_I_N(addr, i) (addr ##_reg - 0x00300000 + (0x40 * i) + 0x8)
+ #define RDMA_SSI_O_N(addr, i) (addr ##_reg - 0x00300000 + (0x40 * i) + 0xc)
+
+-#define RDMA_SSIU_I_N(addr, i, j) (addr ##_reg - 0x00441000 + (0x1000 * (i)) + (((j) / 4) * 0xA000) + (((j) % 4) * 0x400))
++#define RDMA_SSIU_I_N(addr, i, j) (addr ##_reg - 0x00441000 + (0x1000 * (i)) + (((j) / 4) * 0xA000) + (((j) % 4) * 0x400) - (0x4000 * ((i) / 9) * ((j) / 4)))
+ #define RDMA_SSIU_O_N(addr, i, j) RDMA_SSIU_I_N(addr, i, j)
+
+-#define RDMA_SSIU_I_P(addr, i, j) (addr ##_reg - 0x00141000 + (0x1000 * (i)) + (((j) / 4) * 0xA000) + (((j) % 4) * 0x400))
++#define RDMA_SSIU_I_P(addr, i, j) (addr ##_reg - 0x00141000 + (0x1000 * (i)) + (((j) / 4) * 0xA000) + (((j) % 4) * 0x400) - (0x4000 * ((i) / 9) * ((j) / 4)))
+ #define RDMA_SSIU_O_P(addr, i, j) RDMA_SSIU_I_P(addr, i, j)
+
+ #define RDMA_SRC_I_N(addr, i) (addr ##_reg - 0x00500000 + (0x400 * i))
--- /dev/null
+From b0814361a25cba73a224548843ed92d8ea78715a Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Tue, 5 Nov 2019 08:09:51 -0800
+Subject: blkcg: make blkcg_print_stat() print stats only for online blkgs
+
+From: Tejun Heo <tj@kernel.org>
+
+commit b0814361a25cba73a224548843ed92d8ea78715a upstream.
+
+blkcg_print_stat() iterates blkgs under RCU and doesn't test whether
+the blkg is online. This can call into pd_stat_fn() on a pd which is
+still being initialized leading to an oops.
+
+The heaviest operation - recursively summing up rwstat counters - is
+already done while holding the queue_lock. Expand queue_lock to cover
+the other operations and skip the blkg if it isn't online yet. The
+online state is protected by both blkcg and queue locks, so this
+guarantees that only online blkgs are processed.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Reported-by: Roman Gushchin <guro@fb.com>
+Cc: Josef Bacik <jbacik@fb.com>
+Fixes: 903d23f0a354 ("blk-cgroup: allow controllers to output their own stats")
+Cc: stable@vger.kernel.org # v4.19+
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/blk-cgroup.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/block/blk-cgroup.c
++++ b/block/blk-cgroup.c
+@@ -908,9 +908,14 @@ static int blkcg_print_stat(struct seq_f
+ int i;
+ bool has_stats = false;
+
++ spin_lock_irq(&blkg->q->queue_lock);
++
++ if (!blkg->online)
++ goto skip;
++
+ dname = blkg_dev_name(blkg);
+ if (!dname)
+- continue;
++ goto skip;
+
+ /*
+ * Hooray string manipulation, count is the size written NOT
+@@ -920,8 +925,6 @@ static int blkcg_print_stat(struct seq_f
+ */
+ off += scnprintf(buf+off, size-off, "%s ", dname);
+
+- spin_lock_irq(&blkg->q->queue_lock);
+-
+ blkg_rwstat_recursive_sum(blkg, NULL,
+ offsetof(struct blkcg_gq, stat_bytes), &rwstat);
+ rbytes = rwstat.cnt[BLKG_RWSTAT_READ];
+@@ -934,8 +937,6 @@ static int blkcg_print_stat(struct seq_f
+ wios = rwstat.cnt[BLKG_RWSTAT_WRITE];
+ dios = rwstat.cnt[BLKG_RWSTAT_DISCARD];
+
+- spin_unlock_irq(&blkg->q->queue_lock);
+-
+ if (rbytes || wbytes || rios || wios) {
+ has_stats = true;
+ off += scnprintf(buf+off, size-off,
+@@ -973,6 +974,8 @@ static int blkcg_print_stat(struct seq_f
+ seq_commit(sf, -1);
+ }
+ }
++ skip:
++ spin_unlock_irq(&blkg->q->queue_lock);
+ }
+
+ rcu_read_unlock();
--- /dev/null
+From c17add7a1c61a15578e4071ed7bfd460fd041c43 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Wed, 28 Aug 2019 10:33:12 +0800
+Subject: btrfs: Consider system chunk array size for new SYSTEM chunks
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit c17add7a1c61a15578e4071ed7bfd460fd041c43 upstream.
+
+For SYSTEM chunks, despite the regular chunk item size limit, there is
+another limit due to system chunk array size.
+
+The extra limit was removed in a refactoring, so add it back.
+
+Fixes: e3ecdb3fdecf ("btrfs: factor out devs_max setting in __btrfs_alloc_chunk")
+CC: stable@vger.kernel.org # 5.3+
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Reviewed-by: Anand Jain <anand.jain@oracle.com>
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/volumes.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -4976,6 +4976,7 @@ static int __btrfs_alloc_chunk(struct bt
+ } else if (type & BTRFS_BLOCK_GROUP_SYSTEM) {
+ max_stripe_size = SZ_32M;
+ max_chunk_size = 2 * max_stripe_size;
++ devs_max = min_t(int, devs_max, BTRFS_MAX_DEVS_SYS_CHUNK);
+ } else {
+ btrfs_err(info, "invalid chunk type 0x%llx requested",
+ type);
--- /dev/null
+From d98da49977f67394db492f06c00b1fb1cc090c05 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Fri, 11 Oct 2019 09:03:54 -0400
+Subject: btrfs: save i_size to avoid double evaluation of i_size_read in compress_file_range
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit d98da49977f67394db492f06c00b1fb1cc090c05 upstream.
+
+We hit a regression while rolling out 5.2 internally where we were
+hitting the following panic
+
+ kernel BUG at mm/page-writeback.c:2659!
+ RIP: 0010:clear_page_dirty_for_io+0xe6/0x1f0
+ Call Trace:
+ __process_pages_contig+0x25a/0x350
+ ? extent_clear_unlock_delalloc+0x43/0x70
+ submit_compressed_extents+0x359/0x4d0
+ normal_work_helper+0x15a/0x330
+ process_one_work+0x1f5/0x3f0
+ worker_thread+0x2d/0x3d0
+ ? rescuer_thread+0x340/0x340
+ kthread+0x111/0x130
+ ? kthread_create_on_node+0x60/0x60
+ ret_from_fork+0x1f/0x30
+
+This is happening because the page is not locked when doing
+clear_page_dirty_for_io. Looking at the core dump it was because our
+async_extent had a ram_size of 24576 but our async_chunk range only
+spanned 20480, so we had a whole extra page in our ram_size for our
+async_extent.
+
+This happened because we try not to compress pages outside of our
+i_size, however a cleanup patch changed us to do
+
+actual_end = min_t(u64, i_size_read(inode), end + 1);
+
+which is problematic because i_size_read() can evaluate to different
+values in between checking and assigning. So either an expanding
+truncate or a fallocate could increase our i_size while we're doing
+writeout and actual_end would end up being past the range we have
+locked.
+
+I confirmed this was what was happening by installing a debug kernel
+that had
+
+ actual_end = min_t(u64, i_size_read(inode), end + 1);
+ if (actual_end > end + 1) {
+ printk(KERN_ERR "KABOOM\n");
+ actual_end = end + 1;
+ }
+
+and installing it onto 500 boxes of the tier that had been seeing the
+problem regularly. Last night I got my debug message and no panic,
+confirming what I expected.
+
+[ dsterba: the assembly confirms a tiny race window:
+
+ mov 0x20(%rsp),%rax
+ cmp %rax,0x48(%r15) # read
+ movl $0x0,0x18(%rsp)
+ mov %rax,%r12
+ mov %r14,%rax
+ cmovbe 0x48(%r15),%r12 # eval
+
+ Where r15 is inode and 0x48 is offset of i_size.
+
+ The original fix was to revert 62b37622718c that would do an
+ intermediate assignment and this would also avoid the doulble
+ evaluation but is not future-proof, should the compiler merge the
+ stores and call i_size_read anyway.
+
+ There's a patch adding READ_ONCE to i_size_read but that's not being
+ applied at the moment and we need to fix the bug. Instead, emulate
+ READ_ONCE by two barrier()s that's what effectively happens. The
+ assembly confirms single evaluation:
+
+ mov 0x48(%rbp),%rax # read once
+ mov 0x20(%rsp),%rcx
+ mov $0x20,%edx
+ cmp %rax,%rcx
+ cmovbe %rcx,%rax
+ mov %rax,(%rsp)
+ mov %rax,%rcx
+ mov %r14,%rax
+
+ Where 0x48(%rbp) is inode->i_size stored to %eax.
+]
+
+Fixes: 62b37622718c ("btrfs: Remove isize local variable in compress_file_range")
+CC: stable@vger.kernel.org # v5.1+
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+[ changelog updated ]
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/inode.c | 15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+--- a/fs/btrfs/inode.c
++++ b/fs/btrfs/inode.c
+@@ -472,6 +472,7 @@ static noinline void compress_file_range
+ u64 start = async_chunk->start;
+ u64 end = async_chunk->end;
+ u64 actual_end;
++ u64 i_size;
+ int ret = 0;
+ struct page **pages = NULL;
+ unsigned long nr_pages;
+@@ -485,7 +486,19 @@ static noinline void compress_file_range
+ inode_should_defrag(BTRFS_I(inode), start, end, end - start + 1,
+ SZ_16K);
+
+- actual_end = min_t(u64, i_size_read(inode), end + 1);
++ /*
++ * We need to save i_size before now because it could change in between
++ * us evaluating the size and assigning it. This is because we lock and
++ * unlock the page in truncate and fallocate, and then modify the i_size
++ * later on.
++ *
++ * The barriers are to emulate READ_ONCE, remove that once i_size_read
++ * does that for us.
++ */
++ barrier();
++ i_size = i_size_read(inode);
++ barrier();
++ actual_end = min_t(u64, i_size, end + 1);
+ again:
+ will_compress = 0;
+ nr_pages = (end >> PAGE_SHIFT) - (start >> PAGE_SHIFT) + 1;
--- /dev/null
+From 8bb177d18f114358a57d8ae7e206861b48b8b4de Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Wed, 28 Aug 2019 10:33:13 +0800
+Subject: btrfs: tree-checker: Fix wrong check on max devid
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit 8bb177d18f114358a57d8ae7e206861b48b8b4de upstream.
+
+[BUG]
+The following script will cause false alert on devid check.
+ #!/bin/bash
+
+ dev1=/dev/test/test
+ dev2=/dev/test/scratch1
+ mnt=/mnt/btrfs
+
+ umount $dev1 &> /dev/null
+ umount $dev2 &> /dev/null
+ umount $mnt &> /dev/null
+
+ mkfs.btrfs -f $dev1
+
+ mount $dev1 $mnt
+
+ _fail()
+ {
+ echo "!!! FAILED !!!"
+ exit 1
+ }
+
+ for ((i = 0; i < 4096; i++)); do
+ btrfs dev add -f $dev2 $mnt || _fail
+ btrfs dev del $dev1 $mnt || _fail
+ dev_tmp=$dev1
+ dev1=$dev2
+ dev2=$dev_tmp
+ done
+
+[CAUSE]
+Tree-checker uses BTRFS_MAX_DEVS() and BTRFS_MAX_DEVS_SYS_CHUNK() as
+upper limit for devid. But we can have devid holes just like above
+script.
+
+So the check for devid is incorrect and could cause false alert.
+
+[FIX]
+Just remove the whole devid check. We don't have any hard requirement
+for devid assignment.
+
+Furthermore, even devid could get corrupted by a bitflip, we still have
+dev extents verification at mount time, so corrupted data won't sneak
+in.
+
+This fixes fstests btrfs/194.
+
+Reported-by: Anand Jain <anand.jain@oracle.com>
+Fixes: ab4ba2e13346 ("btrfs: tree-checker: Verify dev item")
+CC: stable@vger.kernel.org # 5.2+
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/tree-checker.c | 8 --------
+ 1 file changed, 8 deletions(-)
+
+--- a/fs/btrfs/tree-checker.c
++++ b/fs/btrfs/tree-checker.c
+@@ -686,9 +686,7 @@ static void dev_item_err(const struct ex
+ static int check_dev_item(struct extent_buffer *leaf,
+ struct btrfs_key *key, int slot)
+ {
+- struct btrfs_fs_info *fs_info = leaf->fs_info;
+ struct btrfs_dev_item *ditem;
+- u64 max_devid = max(BTRFS_MAX_DEVS(fs_info), BTRFS_MAX_DEVS_SYS_CHUNK);
+
+ if (key->objectid != BTRFS_DEV_ITEMS_OBJECTID) {
+ dev_item_err(leaf, slot,
+@@ -696,12 +694,6 @@ static int check_dev_item(struct extent_
+ key->objectid, BTRFS_DEV_ITEMS_OBJECTID);
+ return -EUCLEAN;
+ }
+- if (key->offset > max_devid) {
+- dev_item_err(leaf, slot,
+- "invalid devid: has=%llu expect=[0, %llu]",
+- key->offset, max_devid);
+- return -EUCLEAN;
+- }
+ ditem = btrfs_item_ptr(leaf, slot, struct btrfs_dev_item);
+ if (btrfs_device_id(leaf, ditem) != key->offset) {
+ dev_item_err(leaf, slot,
--- /dev/null
+From 3cb3eaac52c0f145d895f4b6c22834d5f02b8569 Mon Sep 17 00:00:00 2001
+From: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
+Date: Tue, 1 Oct 2019 09:40:36 +0200
+Subject: can: c_can: c_can_poll(): only read status register after status IRQ
+
+From: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
+
+commit 3cb3eaac52c0f145d895f4b6c22834d5f02b8569 upstream.
+
+When the status register is read without the status IRQ pending, the
+chip may not raise the interrupt line for an upcoming status interrupt
+and the driver may miss a status interrupt.
+
+It is critical that the BUSOFF status interrupt is forwarded to the
+higher layers, since no more interrupts will follow without
+intervention.
+
+Thanks to Wolfgang and Joe for bringing up the first idea.
+
+Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
+Cc: Wolfgang Grandegger <wg@grandegger.com>
+Cc: Joe Burmeister <joe.burmeister@devtank.co.uk>
+Fixes: fa39b54ccf28 ("can: c_can: Get rid of pointless interrupts")
+Cc: linux-stable <stable@vger.kernel.org>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/c_can/c_can.c | 25 ++++++++++++++++++++-----
+ drivers/net/can/c_can/c_can.h | 1 +
+ 2 files changed, 21 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/can/c_can/c_can.c
++++ b/drivers/net/can/c_can/c_can.c
+@@ -97,6 +97,9 @@
+ #define BTR_TSEG2_SHIFT 12
+ #define BTR_TSEG2_MASK (0x7 << BTR_TSEG2_SHIFT)
+
++/* interrupt register */
++#define INT_STS_PENDING 0x8000
++
+ /* brp extension register */
+ #define BRP_EXT_BRPE_MASK 0x0f
+ #define BRP_EXT_BRPE_SHIFT 0
+@@ -1029,10 +1032,16 @@ static int c_can_poll(struct napi_struct
+ u16 curr, last = priv->last_status;
+ int work_done = 0;
+
+- priv->last_status = curr = priv->read_reg(priv, C_CAN_STS_REG);
+- /* Ack status on C_CAN. D_CAN is self clearing */
+- if (priv->type != BOSCH_D_CAN)
+- priv->write_reg(priv, C_CAN_STS_REG, LEC_UNUSED);
++ /* Only read the status register if a status interrupt was pending */
++ if (atomic_xchg(&priv->sie_pending, 0)) {
++ priv->last_status = curr = priv->read_reg(priv, C_CAN_STS_REG);
++ /* Ack status on C_CAN. D_CAN is self clearing */
++ if (priv->type != BOSCH_D_CAN)
++ priv->write_reg(priv, C_CAN_STS_REG, LEC_UNUSED);
++ } else {
++ /* no change detected ... */
++ curr = last;
++ }
+
+ /* handle state changes */
+ if ((curr & STATUS_EWARN) && (!(last & STATUS_EWARN))) {
+@@ -1083,10 +1092,16 @@ static irqreturn_t c_can_isr(int irq, vo
+ {
+ struct net_device *dev = (struct net_device *)dev_id;
+ struct c_can_priv *priv = netdev_priv(dev);
++ int reg_int;
+
+- if (!priv->read_reg(priv, C_CAN_INT_REG))
++ reg_int = priv->read_reg(priv, C_CAN_INT_REG);
++ if (!reg_int)
+ return IRQ_NONE;
+
++ /* save for later use */
++ if (reg_int & INT_STS_PENDING)
++ atomic_set(&priv->sie_pending, 1);
++
+ /* disable all interrupts and schedule the NAPI */
+ c_can_irq_control(priv, false);
+ napi_schedule(&priv->napi);
+--- a/drivers/net/can/c_can/c_can.h
++++ b/drivers/net/can/c_can/c_can.h
+@@ -198,6 +198,7 @@ struct c_can_priv {
+ struct net_device *dev;
+ struct device *device;
+ atomic_t tx_active;
++ atomic_t sie_pending;
+ unsigned long tx_dir;
+ int last_status;
+ u16 (*read_reg) (const struct c_can_priv *priv, enum reg index);
--- /dev/null
+From db9ee384f6f71f7c5296ce85b7c1a2a2527e7c72 Mon Sep 17 00:00:00 2001
+From: Wen Yang <wenyang@linux.alibaba.com>
+Date: Sat, 28 Sep 2019 22:29:05 +0800
+Subject: can: dev: add missing of_node_put() after calling of_get_child_by_name()
+
+From: Wen Yang <wenyang@linux.alibaba.com>
+
+commit db9ee384f6f71f7c5296ce85b7c1a2a2527e7c72 upstream.
+
+of_node_put() needs to be called when the device node which is got
+from of_get_child_by_name() finished using.
+
+Fixes: 2290aefa2e90 ("can: dev: Add support for limiting configured bitrate")
+Cc: Franklin S Cooper Jr <fcooper@ti.com>
+Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
+Cc: linux-stable <stable@vger.kernel.org>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/dev.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/can/dev.c
++++ b/drivers/net/can/dev.c
+@@ -842,6 +842,7 @@ void of_can_transceiver(struct net_devic
+ return;
+
+ ret = of_property_read_u32(dn, "max-bitrate", &priv->bitrate_max);
++ of_node_put(dn);
+ if ((ret && ret != -EINVAL) || (!ret && !priv->bitrate_max))
+ netdev_warn(dev, "Invalid value for transceiver max bitrate. Ignoring bitrate limit.\n");
+ }
--- /dev/null
+From 5e269324db5adb2f5f6ec9a93a9c7b0672932b47 Mon Sep 17 00:00:00 2001
+From: Joakim Zhang <qiangqing.zhang@nxp.com>
+Date: Thu, 15 Aug 2019 08:00:26 +0000
+Subject: can: flexcan: disable completely the ECC mechanism
+
+From: Joakim Zhang <qiangqing.zhang@nxp.com>
+
+commit 5e269324db5adb2f5f6ec9a93a9c7b0672932b47 upstream.
+
+The ECC (memory error detection and correction) mechanism can be
+activated or not, controlled by the ECCDIS bit in CAN_MECR. When
+disabled, updates on indications and reporting registers are stopped.
+So if want to disable ECC completely, had better assert ECCDIS bit, not
+just mask the related interrupts.
+
+Fixes: cdce844865be ("can: flexcan: add vf610 support for FlexCAN")
+Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
+Cc: linux-stable <stable@vger.kernel.org>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/flexcan.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/can/flexcan.c
++++ b/drivers/net/can/flexcan.c
+@@ -1169,6 +1169,7 @@ static int flexcan_chip_start(struct net
+ reg_mecr = priv->read(®s->mecr);
+ reg_mecr &= ~FLEXCAN_MECR_ECRWRDIS;
+ priv->write(reg_mecr, ®s->mecr);
++ reg_mecr |= FLEXCAN_MECR_ECCDIS;
+ reg_mecr &= ~(FLEXCAN_MECR_NCEFAFRZ | FLEXCAN_MECR_HANCEI_MSK |
+ FLEXCAN_MECR_FANCEI_MSK);
+ priv->write(reg_mecr, ®s->mecr);
--- /dev/null
+From fb5be6a7b4863ecc44963bb80ca614584b6c7817 Mon Sep 17 00:00:00 2001
+From: Navid Emamdoost <navid.emamdoost@gmail.com>
+Date: Thu, 19 Sep 2019 21:44:38 -0500
+Subject: can: gs_usb: gs_can_open(): prevent memory leak
+
+From: Navid Emamdoost <navid.emamdoost@gmail.com>
+
+commit fb5be6a7b4863ecc44963bb80ca614584b6c7817 upstream.
+
+In gs_can_open() if usb_submit_urb() fails the allocated urb should be
+released.
+
+Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
+Cc: linux-stable <stable@vger.kernel.org>
+Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/usb/gs_usb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/can/usb/gs_usb.c
++++ b/drivers/net/can/usb/gs_usb.c
+@@ -623,6 +623,7 @@ static int gs_can_open(struct net_device
+ rc);
+
+ usb_unanchor_urb(urb);
++ usb_free_urb(urb);
+ break;
+ }
+
--- /dev/null
+From 4d6636498c41891d0482a914dd570343a838ad79 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Tue, 1 Oct 2019 12:29:13 +0200
+Subject: can: mcba_usb: fix use-after-free on disconnect
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 4d6636498c41891d0482a914dd570343a838ad79 upstream.
+
+The driver was accessing its driver data after having freed it.
+
+Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
+Cc: stable <stable@vger.kernel.org> # 4.12
+Cc: Remigiusz Kołłątaj <remigiusz.kollataj@mobica.com>
+Reported-by: syzbot+e29b17e5042bbc56fae9@syzkaller.appspotmail.com
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/usb/mcba_usb.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/net/can/usb/mcba_usb.c
++++ b/drivers/net/can/usb/mcba_usb.c
+@@ -876,9 +876,8 @@ static void mcba_usb_disconnect(struct u
+ netdev_info(priv->netdev, "device disconnected\n");
+
+ unregister_candev(priv->netdev);
+- free_candev(priv->netdev);
+-
+ mcba_urb_unlink(priv);
++ free_candev(priv->netdev);
+ }
+
+ static struct usb_driver mcba_usb_driver = {
--- /dev/null
+From de280f403f2996679e2607384980703710576fed Mon Sep 17 00:00:00 2001
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+Date: Tue, 8 Oct 2019 10:35:44 +0200
+Subject: can: peak_usb: fix a potential out-of-sync while decoding packets
+
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+
+commit de280f403f2996679e2607384980703710576fed upstream.
+
+When decoding a buffer received from PCAN-USB, the first timestamp read in
+a packet is a 16-bit coded time base, and the next ones are an 8-bit
+offset to this base, regardless of the type of packet read.
+
+This patch corrects a potential loss of synchronization by using a
+timestamp index read from the buffer, rather than an index of received
+data packets, to determine on the sizeof the timestamp to be read from the
+packet being decoded.
+
+Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
+Fixes: 46be265d3388 ("can: usb: PEAK-System Technik PCAN-USB specific part")
+Cc: linux-stable <stable@vger.kernel.org>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/usb/peak_usb/pcan_usb.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/can/usb/peak_usb/pcan_usb.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb.c
+@@ -100,7 +100,7 @@ struct pcan_usb_msg_context {
+ u8 *end;
+ u8 rec_cnt;
+ u8 rec_idx;
+- u8 rec_data_idx;
++ u8 rec_ts_idx;
+ struct net_device *netdev;
+ struct pcan_usb *pdev;
+ };
+@@ -547,10 +547,15 @@ static int pcan_usb_decode_status(struct
+ mc->ptr += PCAN_USB_CMD_ARGS;
+
+ if (status_len & PCAN_USB_STATUSLEN_TIMESTAMP) {
+- int err = pcan_usb_decode_ts(mc, !mc->rec_idx);
++ int err = pcan_usb_decode_ts(mc, !mc->rec_ts_idx);
+
+ if (err)
+ return err;
++
++ /* Next packet in the buffer will have a timestamp on a single
++ * byte
++ */
++ mc->rec_ts_idx++;
+ }
+
+ switch (f) {
+@@ -632,10 +637,13 @@ static int pcan_usb_decode_data(struct p
+
+ cf->can_dlc = get_can_dlc(rec_len);
+
+- /* first data packet timestamp is a word */
+- if (pcan_usb_decode_ts(mc, !mc->rec_data_idx))
++ /* Only first packet timestamp is a word */
++ if (pcan_usb_decode_ts(mc, !mc->rec_ts_idx))
+ goto decode_failed;
+
++ /* Next packet in the buffer will have a timestamp on a single byte */
++ mc->rec_ts_idx++;
++
+ /* read data */
+ memset(cf->data, 0x0, sizeof(cf->data));
+ if (status_len & PCAN_USB_STATUSLEN_RTR) {
+@@ -688,7 +696,6 @@ static int pcan_usb_decode_msg(struct pe
+ /* handle normal can frames here */
+ } else {
+ err = pcan_usb_decode_data(&mc, sl);
+- mc.rec_data_idx++;
+ }
+ }
+
--- /dev/null
+From f7a1337f0d29b98733c8824e165fca3371d7d4fd Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Wed, 23 Oct 2019 10:27:05 +0200
+Subject: can: peak_usb: fix slab info leak
+
+From: Johan Hovold <johan@kernel.org>
+
+commit f7a1337f0d29b98733c8824e165fca3371d7d4fd upstream.
+
+Fix a small slab info leak due to a failure to clear the command buffer
+at allocation.
+
+The first 16 bytes of the command buffer are always sent to the device
+in pcan_usb_send_cmd() even though only the first two may have been
+initialised in case no argument payload is provided (e.g. when waiting
+for a response).
+
+Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
+Cc: stable <stable@vger.kernel.org> # 3.4
+Reported-by: syzbot+863724e7128e14b26732@syzkaller.appspotmail.com
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+@@ -750,7 +750,7 @@ static int peak_usb_create_dev(const str
+ dev = netdev_priv(netdev);
+
+ /* allocate a buffer large enough to send commands */
+- dev->cmd_buf = kmalloc(PCAN_USB_MAX_CMD_LEN, GFP_KERNEL);
++ dev->cmd_buf = kzalloc(PCAN_USB_MAX_CMD_LEN, GFP_KERNEL);
+ if (!dev->cmd_buf) {
+ err = -ENOMEM;
+ goto lbl_free_candev;
--- /dev/null
+From ca913f1ac024559ebc17f0b599af262f0ad997c9 Mon Sep 17 00:00:00 2001
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+Date: Wed, 9 Oct 2019 15:48:48 +0200
+Subject: can: rx-offload: can_rx_offload_queue_sorted(): fix error handling, avoid skb mem leak
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+
+commit ca913f1ac024559ebc17f0b599af262f0ad997c9 upstream.
+
+If the rx-offload skb_queue is full can_rx_offload_queue_sorted() will
+not queue the skb and return with an error.
+
+None of the callers of this function, issue a kfree_skb() to free the
+not queued skb. This results in a memory leak.
+
+This patch fixes the problem by freeing the skb in case of a full queue.
+The return value is adjusted to -ENOBUFS to better reflect the actual
+problem.
+
+The device stats handling is left to the callers, as this function might
+be used in both the rx and tx path.
+
+Fixes: 55059f2b7f86 ("can: rx-offload: introduce can_rx_offload_get_echo_skb() and can_rx_offload_queue_sorted() functions")
+Cc: linux-stable <stable@vger.kernel.org>
+Cc: Martin Hundebøll <martin@geanix.com>
+Reported-by: Martin Hundebøll <martin@geanix.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/rx-offload.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/can/rx-offload.c
++++ b/drivers/net/can/rx-offload.c
+@@ -207,8 +207,10 @@ int can_rx_offload_queue_sorted(struct c
+ unsigned long flags;
+
+ if (skb_queue_len(&offload->skb_queue) >
+- offload->skb_queue_len_max)
+- return -ENOMEM;
++ offload->skb_queue_len_max) {
++ kfree_skb(skb);
++ return -ENOBUFS;
++ }
+
+ cb = can_rx_offload_get_cb(skb);
+ cb->timestamp = timestamp;
--- /dev/null
+From 3759739426186a924675651b388d1c3963c5710e Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Tue, 1 Oct 2019 12:29:14 +0200
+Subject: can: usb_8dev: fix use-after-free on disconnect
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 3759739426186a924675651b388d1c3963c5710e upstream.
+
+The driver was accessing its driver data after having freed it.
+
+Fixes: 0024d8ad1639 ("can: usb_8dev: Add support for USB2CAN interface from 8 devices")
+Cc: stable <stable@vger.kernel.org> # 3.9
+Cc: Bernd Krumboeck <b.krumboeck@gmail.com>
+Cc: Wolfgang Grandegger <wg@grandegger.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/usb/usb_8dev.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/net/can/usb/usb_8dev.c
++++ b/drivers/net/can/usb/usb_8dev.c
+@@ -996,9 +996,8 @@ static void usb_8dev_disconnect(struct u
+ netdev_info(priv->netdev, "device disconnected\n");
+
+ unregister_netdev(priv->netdev);
+- free_candev(priv->netdev);
+-
+ unlink_all_urbs(priv);
++ free_candev(priv->netdev);
+ }
+
+ }
--- /dev/null
+From 1f08529c84cfecaf1261ed9b7e17fab18541c58f Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Tue, 29 Oct 2019 13:53:29 +0000
+Subject: ceph: add missing check in d_revalidate snapdir handling
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit 1f08529c84cfecaf1261ed9b7e17fab18541c58f upstream.
+
+We should not play with dcache without parent locked...
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ceph/inode.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ceph/inode.c
++++ b/fs/ceph/inode.c
+@@ -1432,6 +1432,7 @@ retry_lookup:
+ dout(" final dn %p\n", dn);
+ } else if ((req->r_op == CEPH_MDS_OP_LOOKUPSNAP ||
+ req->r_op == CEPH_MDS_OP_MKSNAP) &&
++ test_bit(CEPH_MDS_R_PARENT_LOCKED, &req->r_req_flags) &&
+ !test_bit(CEPH_MDS_R_ABORTED, &req->r_req_flags)) {
+ struct inode *dir = req->r_parent;
+
--- /dev/null
+From a3a0819388b2bf15e7eafe38ff6aacfc27b12df0 Mon Sep 17 00:00:00 2001
+From: Luis Henriques <lhenriques@suse.com>
+Date: Thu, 31 Oct 2019 11:49:39 +0000
+Subject: ceph: don't allow copy_file_range when stripe_count != 1
+
+From: Luis Henriques <lhenriques@suse.com>
+
+commit a3a0819388b2bf15e7eafe38ff6aacfc27b12df0 upstream.
+
+copy_file_range tries to use the OSD 'copy-from' operation, which simply
+performs a full object copy. Unfortunately, the implementation of this
+system call assumes that stripe_count is always set to 1 and doesn't take
+into account that the data may be striped across an object set. If the
+file layout has stripe_count different from 1, then the destination file
+data will be corrupted.
+
+For example:
+
+Consider a 8 MiB file with 4 MiB object size, stripe_count of 2 and
+stripe_size of 2 MiB; the first half of the file will be filled with 'A's
+and the second half will be filled with 'B's:
+
+ 0 4M 8M Obj1 Obj2
+ +------+------+ +----+ +----+
+ file: | AAAA | BBBB | | AA | | AA |
+ +------+------+ |----| |----|
+ | BB | | BB |
+ +----+ +----+
+
+If we copy_file_range this file into a new file (which needs to have the
+same file layout!), then it will start by copying the object starting at
+file offset 0 (Obj1). And then it will copy the object starting at file
+offset 4M -- which is Obj1 again.
+
+Unfortunately, the solution for this is to not allow remote object copies
+to be performed when the file layout stripe_count is not 1 and simply
+fallback to the default (VFS) copy_file_range implementation.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Luis Henriques <lhenriques@suse.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ceph/file.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/fs/ceph/file.c
++++ b/fs/ceph/file.c
+@@ -1934,10 +1934,18 @@ static ssize_t __ceph_copy_file_range(st
+ if (ceph_test_mount_opt(ceph_inode_to_client(src_inode), NOCOPYFROM))
+ return -EOPNOTSUPP;
+
++ /*
++ * Striped file layouts require that we copy partial objects, but the
++ * OSD copy-from operation only supports full-object copies. Limit
++ * this to non-striped file layouts for now.
++ */
+ if ((src_ci->i_layout.stripe_unit != dst_ci->i_layout.stripe_unit) ||
+- (src_ci->i_layout.stripe_count != dst_ci->i_layout.stripe_count) ||
+- (src_ci->i_layout.object_size != dst_ci->i_layout.object_size))
++ (src_ci->i_layout.stripe_count != 1) ||
++ (dst_ci->i_layout.stripe_count != 1) ||
++ (src_ci->i_layout.object_size != dst_ci->i_layout.object_size)) {
++ dout("Invalid src/dst files layout\n");
+ return -EOPNOTSUPP;
++ }
+
+ if (len < src_ci->i_layout.object_size)
+ return -EOPNOTSUPP; /* no remote copy will be done */
--- /dev/null
+From 5bb5e6ee6f5c557dcd19822eccd7bcced1e1a410 Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@kernel.org>
+Date: Wed, 30 Oct 2019 12:15:10 -0400
+Subject: ceph: don't try to handle hashed dentries in non-O_CREAT atomic_open
+
+From: Jeff Layton <jlayton@kernel.org>
+
+commit 5bb5e6ee6f5c557dcd19822eccd7bcced1e1a410 upstream.
+
+If ceph_atomic_open is handed a !d_in_lookup dentry, then that means
+that it already passed d_revalidate so we *know* that it's negative (or
+at least was very recently). Just return -ENOENT in that case.
+
+This also addresses a subtle bug in dentry handling. Non-O_CREAT opens
+call atomic_open with the parent's i_rwsem shared, but calling
+d_splice_alias on a hashed dentry requires the exclusive lock.
+
+If ceph_atomic_open receives a hashed, negative dentry on a non-O_CREAT
+open, and another client were to race in and create the file before we
+issue our OPEN, ceph_fill_trace could end up calling d_splice_alias on
+the dentry with the new inode with insufficient locks.
+
+Cc: stable@vger.kernel.org
+Reported-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ceph/file.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/ceph/file.c
++++ b/fs/ceph/file.c
+@@ -458,6 +458,9 @@ int ceph_atomic_open(struct inode *dir,
+ err = ceph_security_init_secctx(dentry, mode, &as_ctx);
+ if (err < 0)
+ goto out_ctx;
++ } else if (!d_in_lookup(dentry)) {
++ /* If it's not being looked up, it's negative */
++ return -ENOENT;
+ }
+
+ /* do the open */
--- /dev/null
+From aa8dd816732b2bab28c54bc4d2ccf3fc8a6e0892 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Tue, 29 Oct 2019 13:50:19 +0000
+Subject: ceph: fix RCU case handling in ceph_d_revalidate()
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit aa8dd816732b2bab28c54bc4d2ccf3fc8a6e0892 upstream.
+
+For RCU case ->d_revalidate() is called with rcu_read_lock() and
+without pinning the dentry passed to it. Which means that it
+can't rely upon ->d_inode remaining stable; that's the reason
+for d_inode_rcu(), actually.
+
+Make sure we don't reload ->d_inode there.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ceph/dir.c | 15 ++++++++-------
+ 1 file changed, 8 insertions(+), 7 deletions(-)
+
+--- a/fs/ceph/dir.c
++++ b/fs/ceph/dir.c
+@@ -1553,36 +1553,37 @@ static int ceph_d_revalidate(struct dent
+ {
+ int valid = 0;
+ struct dentry *parent;
+- struct inode *dir;
++ struct inode *dir, *inode;
+
+ if (flags & LOOKUP_RCU) {
+ parent = READ_ONCE(dentry->d_parent);
+ dir = d_inode_rcu(parent);
+ if (!dir)
+ return -ECHILD;
++ inode = d_inode_rcu(dentry);
+ } else {
+ parent = dget_parent(dentry);
+ dir = d_inode(parent);
++ inode = d_inode(dentry);
+ }
+
+ dout("d_revalidate %p '%pd' inode %p offset %lld\n", dentry,
+- dentry, d_inode(dentry), ceph_dentry(dentry)->offset);
++ dentry, inode, ceph_dentry(dentry)->offset);
+
+ /* always trust cached snapped dentries, snapdir dentry */
+ if (ceph_snap(dir) != CEPH_NOSNAP) {
+ dout("d_revalidate %p '%pd' inode %p is SNAPPED\n", dentry,
+- dentry, d_inode(dentry));
++ dentry, inode);
+ valid = 1;
+- } else if (d_really_is_positive(dentry) &&
+- ceph_snap(d_inode(dentry)) == CEPH_SNAPDIR) {
++ } else if (inode && ceph_snap(inode) == CEPH_SNAPDIR) {
+ valid = 1;
+ } else {
+ valid = dentry_lease_is_valid(dentry, flags);
+ if (valid == -ECHILD)
+ return valid;
+ if (valid || dir_lease_is_valid(dir, dentry)) {
+- if (d_really_is_positive(dentry))
+- valid = ceph_is_any_caps(d_inode(dentry));
++ if (inode)
++ valid = ceph_is_any_caps(inode);
+ else
+ valid = 1;
+ }
--- /dev/null
+From ea60ed6fcf29eebc78f2ce91491e6309ee005a01 Mon Sep 17 00:00:00 2001
+From: Luis Henriques <lhenriques@suse.com>
+Date: Fri, 25 Oct 2019 14:05:24 +0100
+Subject: ceph: fix use-after-free in __ceph_remove_cap()
+
+From: Luis Henriques <lhenriques@suse.com>
+
+commit ea60ed6fcf29eebc78f2ce91491e6309ee005a01 upstream.
+
+KASAN reports a use-after-free when running xfstest generic/531, with the
+following trace:
+
+[ 293.903362] kasan_report+0xe/0x20
+[ 293.903365] rb_erase+0x1f/0x790
+[ 293.903370] __ceph_remove_cap+0x201/0x370
+[ 293.903375] __ceph_remove_caps+0x4b/0x70
+[ 293.903380] ceph_evict_inode+0x4e/0x360
+[ 293.903386] evict+0x169/0x290
+[ 293.903390] __dentry_kill+0x16f/0x250
+[ 293.903394] dput+0x1c6/0x440
+[ 293.903398] __fput+0x184/0x330
+[ 293.903404] task_work_run+0xb9/0xe0
+[ 293.903410] exit_to_usermode_loop+0xd3/0xe0
+[ 293.903413] do_syscall_64+0x1a0/0x1c0
+[ 293.903417] entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+This happens because __ceph_remove_cap() may queue a cap release
+(__ceph_queue_cap_release) which can be scheduled before that cap is
+removed from the inode list with
+
+ rb_erase(&cap->ci_node, &ci->i_caps);
+
+And, when this finally happens, the use-after-free will occur.
+
+This can be fixed by removing the cap from the inode list before being
+removed from the session list, and thus eliminating the risk of an UAF.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Luis Henriques <lhenriques@suse.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ceph/caps.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/fs/ceph/caps.c
++++ b/fs/ceph/caps.c
+@@ -1087,6 +1087,11 @@ void __ceph_remove_cap(struct ceph_cap *
+
+ dout("__ceph_remove_cap %p from %p\n", cap, &ci->vfs_inode);
+
++ /* remove from inode's cap rbtree, and clear auth cap */
++ rb_erase(&cap->ci_node, &ci->i_caps);
++ if (ci->i_auth_cap == cap)
++ ci->i_auth_cap = NULL;
++
+ /* remove from session list */
+ spin_lock(&session->s_cap_lock);
+ if (session->s_cap_iterator == cap) {
+@@ -1120,11 +1125,6 @@ void __ceph_remove_cap(struct ceph_cap *
+
+ spin_unlock(&session->s_cap_lock);
+
+- /* remove from inode list */
+- rb_erase(&cap->ci_node, &ci->i_caps);
+- if (ci->i_auth_cap == cap)
+- ci->i_auth_cap = NULL;
+-
+ if (removed)
+ ceph_put_cap(mdsc, cap);
+
--- /dev/null
+From fa729c4df558936b4a1a7b3e2234011f44ede28b Mon Sep 17 00:00:00 2001
+From: Christian Brauner <christian.brauner@ubuntu.com>
+Date: Thu, 31 Oct 2019 12:36:08 +0100
+Subject: clone3: validate stack arguments
+
+From: Christian Brauner <christian.brauner@ubuntu.com>
+
+commit fa729c4df558936b4a1a7b3e2234011f44ede28b upstream.
+
+Validate the stack arguments and setup the stack depening on whether or not
+it is growing down or up.
+
+Legacy clone() required userspace to know in which direction the stack is
+growing and pass down the stack pointer appropriately. To make things more
+confusing microblaze uses a variant of the clone() syscall selected by
+CONFIG_CLONE_BACKWARDS3 that takes an additional stack_size argument.
+IA64 has a separate clone2() syscall which also takes an additional
+stack_size argument. Finally, parisc has a stack that is growing upwards.
+Userspace therefore has a lot nasty code like the following:
+
+ #define __STACK_SIZE (8 * 1024 * 1024)
+ pid_t sys_clone(int (*fn)(void *), void *arg, int flags, int *pidfd)
+ {
+ pid_t ret;
+ void *stack;
+
+ stack = malloc(__STACK_SIZE);
+ if (!stack)
+ return -ENOMEM;
+
+ #ifdef __ia64__
+ ret = __clone2(fn, stack, __STACK_SIZE, flags | SIGCHLD, arg, pidfd);
+ #elif defined(__parisc__) /* stack grows up */
+ ret = clone(fn, stack, flags | SIGCHLD, arg, pidfd);
+ #else
+ ret = clone(fn, stack + __STACK_SIZE, flags | SIGCHLD, arg, pidfd);
+ #endif
+ return ret;
+ }
+
+or even crazier variants such as [3].
+
+With clone3() we have the ability to validate the stack. We can check that
+when stack_size is passed, the stack pointer is valid and the other way
+around. We can also check that the memory area userspace gave us is fine to
+use via access_ok(). Furthermore, we probably should not require
+userspace to know in which direction the stack is growing. It is easy
+for us to do this in the kernel and I couldn't find the original
+reasoning behind exposing this detail to userspace.
+
+/* Intentional user visible API change */
+clone3() was released with 5.3. Currently, it is not documented and very
+unclear to userspace how the stack and stack_size argument have to be
+passed. After talking to glibc folks we concluded that trying to change
+clone3() to setup the stack instead of requiring userspace to do this is
+the right course of action.
+Note, that this is an explicit change in user visible behavior we introduce
+with this patch. If it breaks someone's use-case we will revert! (And then
+e.g. place the new behavior under an appropriate flag.)
+Breaking someone's use-case is very unlikely though. First, neither glibc
+nor musl currently expose a wrapper for clone3(). Second, there is no real
+motivation for anyone to use clone3() directly since it does not provide
+features that legacy clone doesn't. New features for clone3() will first
+happen in v5.5 which is why v5.4 is still a good time to try and make that
+change now and backport it to v5.3. Searches on [4] did not reveal any
+packages calling clone3().
+
+[1]: https://lore.kernel.org/r/CAG48ez3q=BeNcuVTKBN79kJui4vC6nw0Bfq6xc-i0neheT17TA@mail.gmail.com
+[2]: https://lore.kernel.org/r/20191028172143.4vnnjpdljfnexaq5@wittgenstein
+[3]: https://github.com/systemd/systemd/blob/5238e9575906297608ff802a27e2ff9effa3b338/src/basic/raw-clone.h#L31
+[4]: https://codesearch.debian.net
+Fixes: 7f192e3cd316 ("fork: add clone3")
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Jann Horn <jannh@google.com>
+Cc: David Howells <dhowells@redhat.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Florian Weimer <fweimer@redhat.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: linux-api@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Cc: <stable@vger.kernel.org> # 5.3
+Cc: GNU C Library <libc-alpha@sourceware.org>
+Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
+Acked-by: Arnd Bergmann <arnd@arndb.de>
+Acked-by: Aleksa Sarai <cyphar@cyphar.com>
+Link: https://lore.kernel.org/r/20191031113608.20713-1-christian.brauner@ubuntu.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/fork.c | 33 ++++++++++++++++++++++++++++++++-
+ 1 file changed, 32 insertions(+), 1 deletion(-)
+
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -2586,7 +2586,35 @@ noinline static int copy_clone_args_from
+ return 0;
+ }
+
+-static bool clone3_args_valid(const struct kernel_clone_args *kargs)
++/**
++ * clone3_stack_valid - check and prepare stack
++ * @kargs: kernel clone args
++ *
++ * Verify that the stack arguments userspace gave us are sane.
++ * In addition, set the stack direction for userspace since it's easy for us to
++ * determine.
++ */
++static inline bool clone3_stack_valid(struct kernel_clone_args *kargs)
++{
++ if (kargs->stack == 0) {
++ if (kargs->stack_size > 0)
++ return false;
++ } else {
++ if (kargs->stack_size == 0)
++ return false;
++
++ if (!access_ok((void __user *)kargs->stack, kargs->stack_size))
++ return false;
++
++#if !defined(CONFIG_STACK_GROWSUP) && !defined(CONFIG_IA64)
++ kargs->stack += kargs->stack_size;
++#endif
++ }
++
++ return true;
++}
++
++static bool clone3_args_valid(struct kernel_clone_args *kargs)
+ {
+ /*
+ * All lower bits of the flag word are taken.
+@@ -2606,6 +2634,9 @@ static bool clone3_args_valid(const stru
+ kargs->exit_signal)
+ return false;
+
++ if (!clone3_stack_valid(kargs))
++ return false;
++
+ return true;
+ }
+
--- /dev/null
+From c31432fa7f825de0e19838f1ac7746381c509ec4 Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Date: Thu, 31 Oct 2019 12:26:20 -0700
+Subject: cpufreq: intel_pstate: Fix invalid EPB setting
+
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+commit c31432fa7f825de0e19838f1ac7746381c509ec4 upstream.
+
+The max value of EPB can only be 0x0F. Attempting to set more than that
+triggers an "unchecked MSR access error" warning which happens in
+intel_pstate_hwp_force_min_perf() called via cpufreq stop_cpu().
+
+However, it is not even necessary to touch the EPB from intel_pstate,
+because it is restored on every CPU online by the intel_epb.c code,
+so let that code do the right thing and drop the redundant (and
+incorrect) EPB update from intel_pstate.
+
+Fixes: af3b7379e2d70 ("cpufreq: intel_pstate: Force HWP min perf before offline")
+Reported-by: Qian Cai <cai@lca.pw>
+Cc: 5.2+ <stable@vger.kernel.org> # 5.2+
+Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+[ rjw: Changelog ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/intel_pstate.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/cpufreq/intel_pstate.c
++++ b/drivers/cpufreq/intel_pstate.c
+@@ -846,11 +846,9 @@ static void intel_pstate_hwp_force_min_p
+ value |= HWP_MAX_PERF(min_perf);
+ value |= HWP_MIN_PERF(min_perf);
+
+- /* Set EPP/EPB to min */
++ /* Set EPP to min */
+ if (boot_cpu_has(X86_FEATURE_HWP_EPP))
+ value |= HWP_ENERGY_PERF_PREFERENCE(HWP_EPP_POWERSAVE);
+- else
+- intel_pstate_set_epb(cpu, HWP_EPP_BALANCE_POWERSAVE);
+
+ wrmsrl_on_cpu(cpu, MSR_HWP_REQUEST, value);
+ }
--- /dev/null
+From 2c409ba81be25516afe05ae27a4a15da01740b01 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Wed, 30 Oct 2019 10:21:28 -0400
+Subject: drm/radeon: fix si_enable_smc_cac() failed issue
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 2c409ba81be25516afe05ae27a4a15da01740b01 upstream.
+
+Need to set the dte flag on this asic.
+
+Port the fix from amdgpu:
+5cb818b861be114 ("drm/amd/amdgpu: fix si_enable_smc_cac() failed issue")
+
+Reviewed-by: Yong Zhao <yong.zhao@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/si_dpm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/radeon/si_dpm.c
++++ b/drivers/gpu/drm/radeon/si_dpm.c
+@@ -1958,6 +1958,7 @@ static void si_initialize_powertune_defa
+ case 0x682C:
+ si_pi->cac_weights = cac_weights_cape_verde_pro;
+ si_pi->dte_data = dte_data_sun_xt;
++ update_dte_from_pl2 = true;
+ break;
+ case 0x6825:
+ case 0x6827:
--- /dev/null
+From 5cbf2fff3bba8d3c6a4d47c1754de1cf57e2b01f Mon Sep 17 00:00:00 2001
+From: Kevin Hao <haokexin@gmail.com>
+Date: Tue, 5 Nov 2019 21:16:57 -0800
+Subject: dump_stack: avoid the livelock of the dump_lock
+
+From: Kevin Hao <haokexin@gmail.com>
+
+commit 5cbf2fff3bba8d3c6a4d47c1754de1cf57e2b01f upstream.
+
+In the current code, we use the atomic_cmpxchg() to serialize the output
+of the dump_stack(), but this implementation suffers the thundering herd
+problem. We have observed such kind of livelock on a Marvell cn96xx
+board(24 cpus) when heavily using the dump_stack() in a kprobe handler.
+Actually we can let the competitors to wait for the releasing of the
+lock before jumping to atomic_cmpxchg(). This will definitely mitigate
+the thundering herd problem. Thanks Linus for the suggestion.
+
+[akpm@linux-foundation.org: fix comment]
+Link: http://lkml.kernel.org/r/20191030031637.6025-1-haokexin@gmail.com
+Fixes: b58d977432c8 ("dump_stack: serialize the output from dump_stack()")
+Signed-off-by: Kevin Hao <haokexin@gmail.com>
+Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ lib/dump_stack.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/lib/dump_stack.c
++++ b/lib/dump_stack.c
+@@ -106,7 +106,12 @@ retry:
+ was_locked = 1;
+ } else {
+ local_irq_restore(flags);
+- cpu_relax();
++ /*
++ * Wait for the lock to release before jumping to
++ * atomic_cmpxchg() in order to mitigate the thundering herd
++ * problem.
++ */
++ do { cpu_relax(); } while (atomic_read(&dump_lock) != -1);
+ goto retry;
+ }
+
--- /dev/null
+From ff479731c3859609530416a18ddb3db5db019b66 Mon Sep 17 00:00:00 2001
+From: Jason Gerecke <killertofu@gmail.com>
+Date: Wed, 6 Nov 2019 11:59:46 -0800
+Subject: HID: wacom: generic: Treat serial number and related fields as unsigned
+
+From: Jason Gerecke <killertofu@gmail.com>
+
+commit ff479731c3859609530416a18ddb3db5db019b66 upstream.
+
+The HID descriptors for most Wacom devices oddly declare the serial
+number and other related fields as signed integers. When these numbers
+are ingested by the HID subsystem, they are automatically sign-extended
+into 32-bit integers. We treat the fields as unsigned elsewhere in the
+kernel and userspace, however, so this sign-extension causes problems.
+In particular, the sign-extended tool ID sent to userspace as ABS_MISC
+does not properly match unsigned IDs used by xf86-input-wacom and libwacom.
+
+We introduce a function 'wacom_s32tou' that can undo the automatic sign
+extension performed by 'hid_snto32'. We call this function when processing
+the serial number and related fields to ensure that we are dealing with
+and reporting the unsigned form. We opt to use this method rather than
+adding a descriptor fixup in 'wacom_hid_usage_quirk' since it should be
+more robust in the face of future devices.
+
+Ref: https://github.com/linuxwacom/input-wacom/issues/134
+Fixes: f85c9dc678 ("HID: wacom: generic: Support tool ID and additional tool types")
+CC: <stable@vger.kernel.org> # v4.10+
+Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
+Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/wacom.h | 15 +++++++++++++++
+ drivers/hid/wacom_wac.c | 10 ++++++----
+ 2 files changed, 21 insertions(+), 4 deletions(-)
+
+--- a/drivers/hid/wacom.h
++++ b/drivers/hid/wacom.h
+@@ -202,6 +202,21 @@ static inline void wacom_schedule_work(s
+ }
+ }
+
++/*
++ * Convert a signed 32-bit integer to an unsigned n-bit integer. Undoes
++ * the normally-helpful work of 'hid_snto32' for fields that use signed
++ * ranges for questionable reasons.
++ */
++static inline __u32 wacom_s32tou(s32 value, __u8 n)
++{
++ switch (n) {
++ case 8: return ((__u8)value);
++ case 16: return ((__u16)value);
++ case 32: return ((__u32)value);
++ }
++ return value & (1 << (n - 1)) ? value & (~(~0U << n)) : value;
++}
++
+ extern const struct hid_device_id wacom_ids[];
+
+ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len);
+--- a/drivers/hid/wacom_wac.c
++++ b/drivers/hid/wacom_wac.c
+@@ -2258,7 +2258,7 @@ static void wacom_wac_pen_event(struct h
+ case HID_DG_TOOLSERIALNUMBER:
+ if (value) {
+ wacom_wac->serial[0] = (wacom_wac->serial[0] & ~0xFFFFFFFFULL);
+- wacom_wac->serial[0] |= (__u32)value;
++ wacom_wac->serial[0] |= wacom_s32tou(value, field->report_size);
+ }
+ return;
+ case HID_DG_TWIST:
+@@ -2274,15 +2274,17 @@ static void wacom_wac_pen_event(struct h
+ return;
+ case WACOM_HID_WD_SERIALHI:
+ if (value) {
++ __u32 raw_value = wacom_s32tou(value, field->report_size);
++
+ wacom_wac->serial[0] = (wacom_wac->serial[0] & 0xFFFFFFFF);
+- wacom_wac->serial[0] |= ((__u64)value) << 32;
++ wacom_wac->serial[0] |= ((__u64)raw_value) << 32;
+ /*
+ * Non-USI EMR devices may contain additional tool type
+ * information here. See WACOM_HID_WD_TOOLTYPE case for
+ * more details.
+ */
+ if (value >> 20 == 1) {
+- wacom_wac->id[0] |= value & 0xFFFFF;
++ wacom_wac->id[0] |= raw_value & 0xFFFFF;
+ }
+ }
+ return;
+@@ -2294,7 +2296,7 @@ static void wacom_wac_pen_event(struct h
+ * bitwise OR so the complete value can be built
+ * up over time :(
+ */
+- wacom_wac->id[0] |= value;
++ wacom_wac->id[0] |= wacom_s32tou(value, field->report_size);
+ return;
+ case WACOM_HID_WD_OFFSETLEFT:
+ if (features->offset_left && value != features->offset_left)
--- /dev/null
+From e6afcf6c598d6f3a0c9c408bfeddb3f5730608b0 Mon Sep 17 00:00:00 2001
+From: Fabrice Gasnier <fabrice.gasnier@st.com>
+Date: Fri, 25 Oct 2019 17:04:20 +0200
+Subject: iio: adc: stm32-adc: fix stopping dma
+
+From: Fabrice Gasnier <fabrice.gasnier@st.com>
+
+commit e6afcf6c598d6f3a0c9c408bfeddb3f5730608b0 upstream.
+
+There maybe a race when using dmaengine_terminate_all(). The predisable
+routine may call iio_triggered_buffer_predisable() prior to a pending DMA
+callback.
+Adopt dmaengine_terminate_sync() to ensure there's no pending DMA request
+before calling iio_triggered_buffer_predisable().
+
+Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support")
+
+Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/stm32-adc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/adc/stm32-adc.c
++++ b/drivers/iio/adc/stm32-adc.c
+@@ -1399,7 +1399,7 @@ static int stm32_adc_dma_start(struct ii
+ cookie = dmaengine_submit(desc);
+ ret = dma_submit_error(cookie);
+ if (ret) {
+- dmaengine_terminate_all(adc->dma_chan);
++ dmaengine_terminate_sync(adc->dma_chan);
+ return ret;
+ }
+
+@@ -1477,7 +1477,7 @@ static void __stm32_adc_buffer_predisabl
+ stm32_adc_conv_irq_disable(adc);
+
+ if (adc->dma_chan)
+- dmaengine_terminate_all(adc->dma_chan);
++ dmaengine_terminate_sync(adc->dma_chan);
+
+ if (stm32_adc_set_trig(indio_dev, NULL))
+ dev_err(&indio_dev->dev, "Can't clear trigger\n");
--- /dev/null
+From 24e1eb5c0d78cfb9750b690bbe997d4d59170258 Mon Sep 17 00:00:00 2001
+From: Alexandru Ardelean <alexandru.ardelean@analog.com>
+Date: Tue, 8 Oct 2019 17:15:37 +0300
+Subject: iio: imu: adis16480: make sure provided frequency is positive
+
+From: Alexandru Ardelean <alexandru.ardelean@analog.com>
+
+commit 24e1eb5c0d78cfb9750b690bbe997d4d59170258 upstream.
+
+It could happen that either `val` or `val2` [provided from userspace] is
+negative. In that case the computed frequency could get a weird value.
+
+Fix this by checking that neither of the 2 variables is negative, and check
+that the computed result is not-zero.
+
+Fixes: e4f959390178 ("iio: imu: adis16480 switch sampling frequency attr to core support")
+Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/imu/adis16480.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/iio/imu/adis16480.c
++++ b/drivers/iio/imu/adis16480.c
+@@ -317,8 +317,11 @@ static int adis16480_set_freq(struct iio
+ struct adis16480 *st = iio_priv(indio_dev);
+ unsigned int t, reg;
+
++ if (val < 0 || val2 < 0)
++ return -EINVAL;
++
+ t = val * 1000 + val2 / 1000;
+- if (t <= 0)
++ if (t == 0)
+ return -EINVAL;
+
+ /*
--- /dev/null
+From 6e82ae6b8d11b948b74e71396efd8e074c415f44 Mon Sep 17 00:00:00 2001
+From: Jean-Baptiste Maneyrol <JManeyrol@invensense.com>
+Date: Wed, 16 Oct 2019 14:43:28 +0000
+Subject: iio: imu: inv_mpu6050: fix no data on MPU6050
+
+From: Jean-Baptiste Maneyrol <JManeyrol@invensense.com>
+
+commit 6e82ae6b8d11b948b74e71396efd8e074c415f44 upstream.
+
+Some chips have a fifo overflow bit issue where the bit is always
+set. The result is that every data is dropped.
+
+Change fifo overflow management by checking fifo count against
+a maximum value.
+
+Add fifo size in chip hardware set of values.
+
+Fixes: f5057e7b2dba ("iio: imu: inv_mpu6050: better fifo overflow handling")
+Cc: stable@vger.kernel.org
+Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 9 +++++++++
+ drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 2 ++
+ drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 15 ++++++++++++---
+ 3 files changed, 23 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
++++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+@@ -114,54 +114,63 @@ static const struct inv_mpu6050_hw hw_in
+ .name = "MPU6050",
+ .reg = ®_set_6050,
+ .config = &chip_config_6050,
++ .fifo_size = 1024,
+ },
+ {
+ .whoami = INV_MPU6500_WHOAMI_VALUE,
+ .name = "MPU6500",
+ .reg = ®_set_6500,
+ .config = &chip_config_6050,
++ .fifo_size = 512,
+ },
+ {
+ .whoami = INV_MPU6515_WHOAMI_VALUE,
+ .name = "MPU6515",
+ .reg = ®_set_6500,
+ .config = &chip_config_6050,
++ .fifo_size = 512,
+ },
+ {
+ .whoami = INV_MPU6000_WHOAMI_VALUE,
+ .name = "MPU6000",
+ .reg = ®_set_6050,
+ .config = &chip_config_6050,
++ .fifo_size = 1024,
+ },
+ {
+ .whoami = INV_MPU9150_WHOAMI_VALUE,
+ .name = "MPU9150",
+ .reg = ®_set_6050,
+ .config = &chip_config_6050,
++ .fifo_size = 1024,
+ },
+ {
+ .whoami = INV_MPU9250_WHOAMI_VALUE,
+ .name = "MPU9250",
+ .reg = ®_set_6500,
+ .config = &chip_config_6050,
++ .fifo_size = 512,
+ },
+ {
+ .whoami = INV_MPU9255_WHOAMI_VALUE,
+ .name = "MPU9255",
+ .reg = ®_set_6500,
+ .config = &chip_config_6050,
++ .fifo_size = 512,
+ },
+ {
+ .whoami = INV_ICM20608_WHOAMI_VALUE,
+ .name = "ICM20608",
+ .reg = ®_set_6500,
+ .config = &chip_config_6050,
++ .fifo_size = 512,
+ },
+ {
+ .whoami = INV_ICM20602_WHOAMI_VALUE,
+ .name = "ICM20602",
+ .reg = ®_set_icm20602,
+ .config = &chip_config_6050,
++ .fifo_size = 1008,
+ },
+ };
+
+--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
++++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
+@@ -100,12 +100,14 @@ struct inv_mpu6050_chip_config {
+ * @name: name of the chip.
+ * @reg: register map of the chip.
+ * @config: configuration of the chip.
++ * @fifo_size: size of the FIFO in bytes.
+ */
+ struct inv_mpu6050_hw {
+ u8 whoami;
+ u8 *name;
+ const struct inv_mpu6050_reg_map *reg;
+ const struct inv_mpu6050_chip_config *config;
++ size_t fifo_size;
+ };
+
+ /*
+--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
++++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
+@@ -180,9 +180,6 @@ irqreturn_t inv_mpu6050_read_fifo(int ir
+ "failed to ack interrupt\n");
+ goto flush_fifo;
+ }
+- /* handle fifo overflow by reseting fifo */
+- if (int_status & INV_MPU6050_BIT_FIFO_OVERFLOW_INT)
+- goto flush_fifo;
+ if (!(int_status & INV_MPU6050_BIT_RAW_DATA_RDY_INT)) {
+ dev_warn(regmap_get_device(st->map),
+ "spurious interrupt with status 0x%x\n", int_status);
+@@ -211,6 +208,18 @@ irqreturn_t inv_mpu6050_read_fifo(int ir
+ if (result)
+ goto end_session;
+ fifo_count = get_unaligned_be16(&data[0]);
++
++ /*
++ * Handle fifo overflow by resetting fifo.
++ * Reset if there is only 3 data set free remaining to mitigate
++ * possible delay between reading fifo count and fifo data.
++ */
++ nb = 3 * bytes_per_datum;
++ if (fifo_count >= st->hw->fifo_size - nb) {
++ dev_warn(regmap_get_device(st->map), "fifo overflow reset\n");
++ goto flush_fifo;
++ }
++
+ /* compute and process all complete datum */
+ nb = fifo_count / bytes_per_datum;
+ inv_mpu6050_update_period(st, pf->timestamp, nb);
--- /dev/null
+From 431f7667bd6889a274913162dfd19cce9d84848e Mon Sep 17 00:00:00 2001
+From: Andreas Klinger <ak@it-klinger.de>
+Date: Sun, 6 Oct 2019 16:29:56 +0200
+Subject: iio: srf04: fix wrong limitation in distance measuring
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Andreas Klinger <ak@it-klinger.de>
+
+commit 431f7667bd6889a274913162dfd19cce9d84848e upstream.
+
+The measured time value in the driver is limited to the maximum distance
+which can be read by the sensor. This limitation was wrong and is fixed
+by this patch.
+
+It also takes into account that we are supporting a variety of sensors
+today and that the recently added sensors have a higher maximum
+distance range.
+
+Changes in v2:
+- Added a Tested-by
+
+Suggested-by: Zbyněk Kocur <zbynek.kocur@fel.cvut.cz>
+Tested-by: Zbyněk Kocur <zbynek.kocur@fel.cvut.cz>
+Signed-off-by: Andreas Klinger <ak@it-klinger.de>
+Cc:<Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/proximity/srf04.c | 29 +++++++++++++++--------------
+ 1 file changed, 15 insertions(+), 14 deletions(-)
+
+--- a/drivers/iio/proximity/srf04.c
++++ b/drivers/iio/proximity/srf04.c
+@@ -110,7 +110,7 @@ static int srf04_read(struct srf04_data
+ udelay(data->cfg->trigger_pulse_us);
+ gpiod_set_value(data->gpiod_trig, 0);
+
+- /* it cannot take more than 20 ms */
++ /* it should not take more than 20 ms until echo is rising */
+ ret = wait_for_completion_killable_timeout(&data->rising, HZ/50);
+ if (ret < 0) {
+ mutex_unlock(&data->lock);
+@@ -120,7 +120,8 @@ static int srf04_read(struct srf04_data
+ return -ETIMEDOUT;
+ }
+
+- ret = wait_for_completion_killable_timeout(&data->falling, HZ/50);
++ /* it cannot take more than 50 ms until echo is falling */
++ ret = wait_for_completion_killable_timeout(&data->falling, HZ/20);
+ if (ret < 0) {
+ mutex_unlock(&data->lock);
+ return ret;
+@@ -135,19 +136,19 @@ static int srf04_read(struct srf04_data
+
+ dt_ns = ktime_to_ns(ktime_dt);
+ /*
+- * measuring more than 3 meters is beyond the capabilities of
+- * the sensor
++ * measuring more than 6,45 meters is beyond the capabilities of
++ * the supported sensors
+ * ==> filter out invalid results for not measuring echos of
+ * another us sensor
+ *
+ * formula:
+- * distance 3 m
+- * time = ---------- = --------- = 9404389 ns
+- * speed 319 m/s
++ * distance 6,45 * 2 m
++ * time = ---------- = ------------ = 40438871 ns
++ * speed 319 m/s
+ *
+ * using a minimum speed at -20 °C of 319 m/s
+ */
+- if (dt_ns > 9404389)
++ if (dt_ns > 40438871)
+ return -EIO;
+
+ time_ns = dt_ns;
+@@ -159,20 +160,20 @@ static int srf04_read(struct srf04_data
+ * with Temp in °C
+ * and speed in m/s
+ *
+- * use 343 m/s as ultrasonic speed at 20 °C here in absence of the
++ * use 343,5 m/s as ultrasonic speed at 20 °C here in absence of the
+ * temperature
+ *
+ * therefore:
+- * time 343
+- * distance = ------ * -----
+- * 10^6 2
++ * time 343,5 time * 106
++ * distance = ------ * ------- = ------------
++ * 10^6 2 617176
+ * with time in ns
+ * and distance in mm (one way)
+ *
+- * because we limit to 3 meters the multiplication with 343 just
++ * because we limit to 6,45 meters the multiplication with 106 just
+ * fits into 32 bit
+ */
+- distance_mm = time_ns * 343 / 2000000;
++ distance_mm = time_ns * 106 / 617176;
+
+ return distance_mm;
+ }
--- /dev/null
+From 87c0b9c79ec136ea76a14a88d675a746bc6a87f9 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Mon, 28 Oct 2019 09:06:45 +0200
+Subject: intel_th: gth: Fix the window switching sequence
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 87c0b9c79ec136ea76a14a88d675a746bc6a87f9 upstream.
+
+Commit 8116db57cf16 ("intel_th: Add switch triggering support") added
+a trigger assertion of the CTS, but forgot to de-assert it at the end
+of the sequence. This results in window switches randomly not happening.
+
+Fix that by de-asserting the trigger at the end of the window switch
+sequence.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Fixes: 8116db57cf16 ("intel_th: Add switch triggering support")
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191028070651.9770-2-alexander.shishkin@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwtracing/intel_th/gth.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/gth.c
++++ b/drivers/hwtracing/intel_th/gth.c
+@@ -626,6 +626,9 @@ static void intel_th_gth_switch(struct i
+ if (!count)
+ dev_dbg(&thdev->dev, "timeout waiting for CTS Trigger\n");
+
++ /* De-assert the trigger */
++ iowrite32(0, gth->base + REG_CTS_CTL);
++
+ intel_th_gth_stop(gth, output, false);
+ intel_th_gth_start(gth, output);
+ }
--- /dev/null
+From 3adbb5718dd5264666ddbc2b9b43799d292e9cb6 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Mon, 28 Oct 2019 09:06:50 +0200
+Subject: intel_th: pci: Add Comet Lake PCH support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 3adbb5718dd5264666ddbc2b9b43799d292e9cb6 upstream.
+
+This adds support for Intel TH on Comet Lake PCH.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20191028070651.9770-7-alexander.shishkin@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwtracing/intel_th/pci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -200,6 +200,11 @@ static const struct pci_device_id intel_
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
+ {
++ /* Comet Lake PCH */
++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x06a6),
++ .driver_data = (kernel_ulong_t)&intel_th_2x,
++ },
++ {
+ /* Ice Lake NNPI */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x45c5),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
--- /dev/null
+From 9d55499d8da49e9261e95a490f3fda41d955f505 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Mon, 28 Oct 2019 09:06:51 +0200
+Subject: intel_th: pci: Add Jasper Lake PCH support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 9d55499d8da49e9261e95a490f3fda41d955f505 upstream.
+
+This adds support for Intel TH on Jasper Lake PCH.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20191028070651.9770-8-alexander.shishkin@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwtracing/intel_th/pci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -214,6 +214,11 @@ static const struct pci_device_id intel_
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa0a6),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
++ {
++ /* Jasper Lake PCH */
++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4da6),
++ .driver_data = (kernel_ulong_t)&intel_th_2x,
++ },
+ { 0 },
+ };
+
--- /dev/null
+From ec649c9d454ea372dcf16cccf48250994f1d7788 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Tue, 5 Nov 2019 21:16:48 -0800
+Subject: mm/khugepaged: fix might_sleep() warn with CONFIG_HIGHPTE=y
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit ec649c9d454ea372dcf16cccf48250994f1d7788 upstream.
+
+I got some khugepaged spew on a 32bit x86:
+
+ BUG: sleeping function called from invalid context at include/linux/mmu_notifier.h:346
+ in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 25, name: khugepaged
+ INFO: lockdep is turned off.
+ CPU: 1 PID: 25 Comm: khugepaged Not tainted 5.4.0-rc5-elk+ #206
+ Hardware name: System manufacturer P5Q-EM/P5Q-EM, BIOS 2203 07/08/2009
+ Call Trace:
+ dump_stack+0x66/0x8e
+ ___might_sleep.cold.96+0x95/0xa6
+ __might_sleep+0x2e/0x80
+ collapse_huge_page.isra.51+0x5ac/0x1360
+ khugepaged+0x9a9/0x20f0
+ kthread+0xf5/0x110
+ ret_from_fork+0x2e/0x38
+
+Looks like it's due to CONFIG_HIGHPTE=y pte_offset_map()->kmap_atomic()
+vs. mmu_notifier_invalidate_range_start(). Let's do the naive approach
+and just reorder the two operations.
+
+Link: http://lkml.kernel.org/r/20191029201513.GG1208@intel.com
+Fixes: 810e24e009cf71 ("mm/mmu_notifiers: annotate with might_sleep()")
+Signed-off-by: Ville Syrjl <ville.syrjala@linux.intel.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Jérôme Glisse <jglisse@redhat.com>
+Cc: Ralph Campbell <rcampbell@nvidia.com>
+Cc: Ira Weiny <ira.weiny@intel.com>
+Cc: Jason Gunthorpe <jgg@mellanox.com>
+Cc: Daniel Vetter <daniel.vetter@intel.com>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/khugepaged.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/mm/khugepaged.c
++++ b/mm/khugepaged.c
+@@ -1016,12 +1016,13 @@ static void collapse_huge_page(struct mm
+
+ anon_vma_lock_write(vma->anon_vma);
+
+- pte = pte_offset_map(pmd, address);
+- pte_ptl = pte_lockptr(mm, pmd);
+-
+ mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, NULL, mm,
+ address, address + HPAGE_PMD_SIZE);
+ mmu_notifier_invalidate_range_start(&range);
++
++ pte = pte_offset_map(pmd, address);
++ pte_ptl = pte_lockptr(mm, pmd);
++
+ pmd_ptl = pmd_lock(mm, pmd); /* probably unnecessary */
+ /*
+ * After this gup_fast can't run anymore. This also removes
--- /dev/null
+From 221ec5c0a46c1a1740f34fb36fc661a5284d01b0 Mon Sep 17 00:00:00 2001
+From: Roman Gushchin <guro@fb.com>
+Date: Tue, 5 Nov 2019 21:17:03 -0800
+Subject: mm: slab: make page_cgroup_ino() to recognize non-compound slab pages properly
+
+From: Roman Gushchin <guro@fb.com>
+
+commit 221ec5c0a46c1a1740f34fb36fc661a5284d01b0 upstream.
+
+page_cgroup_ino() doesn't return a valid memcg pointer for non-compound
+slab pages, because it depends on PgHead AND PgSlab flags to be set to
+determine the memory cgroup from the kmem_cache. It's correct for
+compound pages, but not for generic small pages. Those don't have PgHead
+set, so it ends up returning zero.
+
+Fix this by replacing the condition to PageSlab() && !PageTail().
+
+Before this patch:
+ [root@localhost ~]# ./page-types -c /sys/fs/cgroup/user.slice/user-0.slice/user@0.service/ | grep slab
+ 0x0000000000000080 38 0 _______S___________________________________ slab
+
+After this patch:
+ [root@localhost ~]# ./page-types -c /sys/fs/cgroup/user.slice/user-0.slice/user@0.service/ | grep slab
+ 0x0000000000000080 147 0 _______S___________________________________ slab
+
+Also, hwpoison_filter_task() uses output of page_cgroup_ino() in order
+to filter error injection events based on memcg. So if
+page_cgroup_ino() fails to return memcg pointer, we just fail to inject
+memory error. Considering that hwpoison filter is for testing, affected
+users are limited and the impact should be marginal.
+
+[n-horiguchi@ah.jp.nec.com: changelog additions]
+Link: http://lkml.kernel.org/r/20191031012151.2722280-1-guro@fb.com
+Fixes: 4d96ba353075 ("mm: memcg/slab: stop setting page->mem_cgroup pointer for slab pages")
+Signed-off-by: Roman Gushchin <guro@fb.com>
+Reviewed-by: Shakeel Butt <shakeelb@google.com>
+Acked-by: David Rientjes <rientjes@google.com>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
+Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/memcontrol.c | 2 +-
+ mm/slab.h | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -486,7 +486,7 @@ ino_t page_cgroup_ino(struct page *page)
+ unsigned long ino = 0;
+
+ rcu_read_lock();
+- if (PageHead(page) && PageSlab(page))
++ if (PageSlab(page) && !PageTail(page))
+ memcg = memcg_from_slab_page(page);
+ else
+ memcg = READ_ONCE(page->mem_cgroup);
+--- a/mm/slab.h
++++ b/mm/slab.h
+@@ -259,8 +259,8 @@ static inline struct kmem_cache *memcg_r
+ * Expects a pointer to a slab page. Please note, that PageSlab() check
+ * isn't sufficient, as it returns true also for tail compound slab pages,
+ * which do not have slab_cache pointer set.
+- * So this function assumes that the page can pass PageHead() and PageSlab()
+- * checks.
++ * So this function assumes that the page can pass PageSlab() && !PageTail()
++ * check.
+ *
+ * The kmem_cache can be reparented asynchronously. The caller must ensure
+ * the memcg lifetime, e.g. by taking rcu_read_lock() or cgroup_mutex.
--- /dev/null
+From 30b7244d79651460ff114ba8f7987ed94c86b99a Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Sat, 24 Aug 2019 17:49:55 +0300
+Subject: netfilter: ipset: Fix an error code in ip_set_sockfn_get()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 30b7244d79651460ff114ba8f7987ed94c86b99a upstream.
+
+The copy_to_user() function returns the number of bytes remaining to be
+copied. In this code, that positive return is checked at the end of the
+function and we return zero/success. What we should do instead is
+return -EFAULT.
+
+Fixes: a7b4f989a629 ("netfilter: ipset: IP set core support")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/netfilter/ipset/ip_set_core.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/net/netfilter/ipset/ip_set_core.c
++++ b/net/netfilter/ipset/ip_set_core.c
+@@ -2069,8 +2069,9 @@ ip_set_sockfn_get(struct sock *sk, int o
+ }
+
+ req_version->version = IPSET_PROTOCOL;
+- ret = copy_to_user(user, req_version,
+- sizeof(struct ip_set_req_version));
++ if (copy_to_user(user, req_version,
++ sizeof(struct ip_set_req_version)))
++ ret = -EFAULT;
+ goto done;
+ }
+ case IP_SET_OP_GET_BYNAME: {
+@@ -2129,7 +2130,8 @@ ip_set_sockfn_get(struct sock *sk, int o
+ } /* end of switch(op) */
+
+ copy:
+- ret = copy_to_user(user, data, copylen);
++ if (copy_to_user(user, data, copylen))
++ ret = -EFAULT;
+
+ done:
+ vfree(data);
--- /dev/null
+From 250367c59e6ba0d79d702a059712d66edacd4a1a Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Thu, 31 Oct 2019 11:06:24 +0100
+Subject: netfilter: nf_tables: Align nft_expr private data to 64-bit
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 250367c59e6ba0d79d702a059712d66edacd4a1a upstream.
+
+Invoking the following commands on a 32-bit architecture with strict
+alignment requirements (such as an ARMv7-based Raspberry Pi) results
+in an alignment exception:
+
+ # nft add table ip test-ip4
+ # nft add chain ip test-ip4 output { type filter hook output priority 0; }
+ # nft add rule ip test-ip4 output quota 1025 bytes
+
+Alignment trap: not handling instruction e1b26f9f at [<7f4473f8>]
+Unhandled fault: alignment exception (0x001) at 0xb832e824
+Internal error: : 1 [#1] PREEMPT SMP ARM
+Hardware name: BCM2835
+[<7f4473fc>] (nft_quota_do_init [nft_quota])
+[<7f447448>] (nft_quota_init [nft_quota])
+[<7f4260d0>] (nf_tables_newrule [nf_tables])
+[<7f4168dc>] (nfnetlink_rcv_batch [nfnetlink])
+[<7f416bd0>] (nfnetlink_rcv [nfnetlink])
+[<8078b334>] (netlink_unicast)
+[<8078b664>] (netlink_sendmsg)
+[<8071b47c>] (sock_sendmsg)
+[<8071bd18>] (___sys_sendmsg)
+[<8071ce3c>] (__sys_sendmsg)
+[<8071ce94>] (sys_sendmsg)
+
+The reason is that nft_quota_do_init() calls atomic64_set() on an
+atomic64_t which is only aligned to 32-bit, not 64-bit, because it
+succeeds struct nft_expr in memory which only contains a 32-bit pointer.
+Fix by aligning the nft_expr private data to 64-bit.
+
+Fixes: 96518518cc41 ("netfilter: add nftables")
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Cc: stable@vger.kernel.org # v3.13+
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/net/netfilter/nf_tables.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/include/net/netfilter/nf_tables.h
++++ b/include/net/netfilter/nf_tables.h
+@@ -801,7 +801,8 @@ struct nft_expr_ops {
+ */
+ struct nft_expr {
+ const struct nft_expr_ops *ops;
+- unsigned char data[];
++ unsigned char data[]
++ __attribute__((aligned(__alignof__(u64))));
+ };
+
+ static inline void *nft_expr_priv(const struct nft_expr *expr)
--- /dev/null
+From ab6cd0e5276e24403751e0b3b8ed807738a8571f Mon Sep 17 00:00:00 2001
+From: John Keeping <john@metanate.com>
+Date: Thu, 15 Aug 2019 11:01:44 +0100
+Subject: perf map: Use zalloc for map_groups
+
+From: John Keeping <john@metanate.com>
+
+commit ab6cd0e5276e24403751e0b3b8ed807738a8571f upstream.
+
+In the next commit we will add new fields to map_groups and we need
+these to be null if no value is assigned. The simplest way to achieve
+this is to request zeroed memory from the allocator.
+
+Signed-off-by: John Keeping <john@metanate.com>
+Reviewed-by: Jiri Olsa <jolsa@kernel.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: john keeping <john@metanate.com>
+Link: http://lkml.kernel.org/r/20190815100146.28842-1-john@metanate.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Andres Freund <andres@anarazel.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/map.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/perf/util/map.c
++++ b/tools/perf/util/map.c
+@@ -637,7 +637,7 @@ bool map_groups__empty(struct map_groups
+
+ struct map_groups *map_groups__new(struct machine *machine)
+ {
+- struct map_groups *mg = malloc(sizeof(*mg));
++ struct map_groups *mg = zalloc(sizeof(*mg));
+
+ if (mg != NULL)
+ map_groups__init(mg, machine);
--- /dev/null
+From 722ddfde366fd46205456a9c5ff9b3359dc9a75e Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jolsa@kernel.org>
+Date: Tue, 5 Nov 2019 00:27:11 +0100
+Subject: perf tools: Fix time sorting
+
+From: Jiri Olsa <jolsa@kernel.org>
+
+commit 722ddfde366fd46205456a9c5ff9b3359dc9a75e upstream.
+
+The final sort might get confused when the comparison is done over
+bigger numbers than int like for -s time.
+
+Check the following report for longer workloads:
+
+ $ perf report -s time -F time,overhead --stdio
+
+Fix hist_entry__sort() to properly return int64_t and not possible cut
+int.
+
+Fixes: 043ca389a318 ("perf tools: Use hpp formats to sort final output")
+Signed-off-by: Jiri Olsa <jolsa@kernel.org>
+Reviewed-by: Andi Kleen <ak@linux.intel.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Michael Petlan <mpetlan@redhat.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: stable@vger.kernel.org # v3.16+
+Link: http://lore.kernel.org/lkml/20191104232711.16055-1-jolsa@kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/hist.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/perf/util/hist.c
++++ b/tools/perf/util/hist.c
+@@ -1618,7 +1618,7 @@ int hists__collapse_resort(struct hists
+ return 0;
+ }
+
+-static int hist_entry__sort(struct hist_entry *a, struct hist_entry *b)
++static int64_t hist_entry__sort(struct hist_entry *a, struct hist_entry *b)
+ {
+ struct hists *hists = a->hists;
+ struct perf_hpp_fmt *fmt;
--- /dev/null
+From 29c2c6aa32405dfee4a29911a51ba133edcedb0f Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Mon, 14 Oct 2019 12:51:04 +0300
+Subject: pinctrl: intel: Avoid potential glitches if pin is in GPIO mode
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit 29c2c6aa32405dfee4a29911a51ba133edcedb0f upstream.
+
+When consumer requests a pin, in order to be on the safest side,
+we switch it first to GPIO mode followed by immediate transition
+to the input state. Due to posted writes it's luckily to be a single
+I/O transaction.
+
+However, if firmware or boot loader already configures the pin
+to the GPIO mode, user expects no glitches for the requested pin.
+We may check if the pin is pre-configured and leave it as is
+till the actual consumer toggles its state to avoid glitches.
+
+Fixes: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")
+Depends-on: f5a26acf0162 ("pinctrl: intel: Initialize GPIO properly when used through irqchip")
+Cc: stable@vger.kernel.org
+Cc: fei.yang@intel.com
+Reported-by: Oliver Barta <oliver.barta@aptiv.com>
+Reported-by: Malin Jonsson <malin.jonsson@ericsson.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/intel/pinctrl-intel.c | 21 ++++++++++++++++++++-
+ 1 file changed, 20 insertions(+), 1 deletion(-)
+
+--- a/drivers/pinctrl/intel/pinctrl-intel.c
++++ b/drivers/pinctrl/intel/pinctrl-intel.c
+@@ -52,6 +52,7 @@
+ #define PADCFG0_GPIROUTNMI BIT(17)
+ #define PADCFG0_PMODE_SHIFT 10
+ #define PADCFG0_PMODE_MASK GENMASK(13, 10)
++#define PADCFG0_PMODE_GPIO 0
+ #define PADCFG0_GPIORXDIS BIT(9)
+ #define PADCFG0_GPIOTXDIS BIT(8)
+ #define PADCFG0_GPIORXSTATE BIT(1)
+@@ -307,7 +308,7 @@ static void intel_pin_dbg_show(struct pi
+ cfg1 = readl(intel_get_padcfg(pctrl, pin, PADCFG1));
+
+ mode = (cfg0 & PADCFG0_PMODE_MASK) >> PADCFG0_PMODE_SHIFT;
+- if (!mode)
++ if (mode == PADCFG0_PMODE_GPIO)
+ seq_puts(s, "GPIO ");
+ else
+ seq_printf(s, "mode %d ", mode);
+@@ -428,6 +429,11 @@ static void __intel_gpio_set_direction(v
+ writel(value, padcfg0);
+ }
+
++static int intel_gpio_get_gpio_mode(void __iomem *padcfg0)
++{
++ return (readl(padcfg0) & PADCFG0_PMODE_MASK) >> PADCFG0_PMODE_SHIFT;
++}
++
+ static void intel_gpio_set_gpio_mode(void __iomem *padcfg0)
+ {
+ u32 value;
+@@ -456,7 +462,20 @@ static int intel_gpio_request_enable(str
+ }
+
+ padcfg0 = intel_get_padcfg(pctrl, pin, PADCFG0);
++
++ /*
++ * If pin is already configured in GPIO mode, we assume that
++ * firmware provides correct settings. In such case we avoid
++ * potential glitches on the pin. Otherwise, for the pin in
++ * alternative mode, consumer has to supply respective flags.
++ */
++ if (intel_gpio_get_gpio_mode(padcfg0) == PADCFG0_PMODE_GPIO) {
++ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
++ return 0;
++ }
++
+ intel_gpio_set_gpio_mode(padcfg0);
++
+ /* Disable TX buffer and enable RX (this will be input) */
+ __intel_gpio_set_direction(padcfg0, true);
+
mm-meminit-recalculate-pcpu-batch-and-high-limits-after-init-completes.patch
mm-thp-handle-page-cache-thp-correctly-in-pagetranscompoundmap.patch
mm-vmstat-hide-proc-pagetypeinfo-from-normal-users.patch
+dump_stack-avoid-the-livelock-of-the-dump_lock.patch
+mm-slab-make-page_cgroup_ino-to-recognize-non-compound-slab-pages-properly.patch
+btrfs-consider-system-chunk-array-size-for-new-system-chunks.patch
+btrfs-tree-checker-fix-wrong-check-on-max-devid.patch
+btrfs-save-i_size-to-avoid-double-evaluation-of-i_size_read-in-compress_file_range.patch
+tools-gpio-use-building_out_of_srctree-to-determine-srctree.patch
+pinctrl-intel-avoid-potential-glitches-if-pin-is-in-gpio-mode.patch
+perf-tools-fix-time-sorting.patch
+perf-map-use-zalloc-for-map_groups.patch
+drm-radeon-fix-si_enable_smc_cac-failed-issue.patch
+hid-wacom-generic-treat-serial-number-and-related-fields-as-unsigned.patch
+mm-khugepaged-fix-might_sleep-warn-with-config_highpte-y.patch
+soundwire-depend-on-acpi.patch
+soundwire-depend-on-acpi-of.patch
+soundwire-bus-set-initial-value-to-port_status.patch
+blkcg-make-blkcg_print_stat-print-stats-only-for-online-blkgs.patch
+arm64-do-not-mask-out-pte_rdonly-in-pte_same.patch
+asoc-rsnd-dma-fix-ssi9-4-5-6-7-busif-dma-address.patch
+ceph-fix-use-after-free-in-__ceph_remove_cap.patch
+ceph-fix-rcu-case-handling-in-ceph_d_revalidate.patch
+ceph-add-missing-check-in-d_revalidate-snapdir-handling.patch
+ceph-don-t-try-to-handle-hashed-dentries-in-non-o_creat-atomic_open.patch
+ceph-don-t-allow-copy_file_range-when-stripe_count-1.patch
+iio-adc-stm32-adc-fix-stopping-dma.patch
+iio-imu-adis16480-make-sure-provided-frequency-is-positive.patch
+iio-imu-inv_mpu6050-fix-no-data-on-mpu6050.patch
+iio-srf04-fix-wrong-limitation-in-distance-measuring.patch
+arm-sunxi-fix-cpu-powerdown-on-a83t.patch
+arm-dts-imx6-logicpd-re-enable-snvs-power-key.patch
+cpufreq-intel_pstate-fix-invalid-epb-setting.patch
+clone3-validate-stack-arguments.patch
+netfilter-nf_tables-align-nft_expr-private-data-to-64-bit.patch
+netfilter-ipset-fix-an-error-code-in-ip_set_sockfn_get.patch
+intel_th-gth-fix-the-window-switching-sequence.patch
+intel_th-pci-add-comet-lake-pch-support.patch
+intel_th-pci-add-jasper-lake-pch-support.patch
+x86-dumpstack-64-don-t-evaluate-exception-stacks-before-setup.patch
+x86-apic-32-avoid-bogus-ldr-warnings.patch
+smb3-fix-persistent-handles-reconnect.patch
+can-usb_8dev-fix-use-after-free-on-disconnect.patch
+can-flexcan-disable-completely-the-ecc-mechanism.patch
+can-c_can-c_can_poll-only-read-status-register-after-status-irq.patch
+can-peak_usb-fix-a-potential-out-of-sync-while-decoding-packets.patch
+can-rx-offload-can_rx_offload_queue_sorted-fix-error-handling-avoid-skb-mem-leak.patch
+can-gs_usb-gs_can_open-prevent-memory-leak.patch
+can-dev-add-missing-of_node_put-after-calling-of_get_child_by_name.patch
+can-mcba_usb-fix-use-after-free-on-disconnect.patch
+can-peak_usb-fix-slab-info-leak.patch
--- /dev/null
+From d243af7ab9feb49f11f2c0050d2077e2d9556f9b Mon Sep 17 00:00:00 2001
+From: Pavel Shilovsky <pshilov@microsoft.com>
+Date: Wed, 6 Nov 2019 13:58:15 -0800
+Subject: SMB3: Fix persistent handles reconnect
+
+From: Pavel Shilovsky <pshilov@microsoft.com>
+
+commit d243af7ab9feb49f11f2c0050d2077e2d9556f9b upstream.
+
+When the client hits a network reconnect, it re-opens every open
+file with a create context to reconnect a persistent handle. All
+create context types should be 8-bytes aligned but the padding
+was missed for that one. As a result, some servers don't allow
+us to reconnect handles and return an error. The problem occurs
+when the problematic context is not at the end of the create
+request packet. Fix this by adding a proper padding at the end
+of the reconnect persistent handle context.
+
+Cc: Stable <stable@vger.kernel.org> # 4.19.x
+Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/smb2pdu.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/cifs/smb2pdu.h
++++ b/fs/cifs/smb2pdu.h
+@@ -836,6 +836,7 @@ struct create_durable_handle_reconnect_v
+ struct create_context ccontext;
+ __u8 Name[8];
+ struct durable_reconnect_context_v2 dcontext;
++ __u8 Pad[4];
+ } __packed;
+
+ /* See MS-SMB2 2.2.13.2.5 */
--- /dev/null
+From f1fac63af678b2fc1044ca71fedf1f2ae8bf7c3b Mon Sep 17 00:00:00 2001
+From: Bard Liao <yung-chuan.liao@linux.intel.com>
+Date: Fri, 30 Aug 2019 02:11:35 +0800
+Subject: soundwire: bus: set initial value to port_status
+
+From: Bard Liao <yung-chuan.liao@linux.intel.com>
+
+commit f1fac63af678b2fc1044ca71fedf1f2ae8bf7c3b upstream.
+
+port_status[port_num] are assigned for each port_num in some if
+conditions. So some of the port_status may not be initialized.
+
+Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
+Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Link: https://lore.kernel.org/r/20190829181135.16049-1-yung-chuan.liao@linux.intel.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/soundwire/bus.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/soundwire/bus.c
++++ b/drivers/soundwire/bus.c
+@@ -803,7 +803,7 @@ static int sdw_handle_port_interrupt(str
+ static int sdw_handle_slave_alerts(struct sdw_slave *slave)
+ {
+ struct sdw_slave_intr_status slave_intr;
+- u8 clear = 0, bit, port_status[15];
++ u8 clear = 0, bit, port_status[15] = {0};
+ int port_num, stat, ret, count = 0;
+ unsigned long port;
+ bool slave_notify = false;
--- /dev/null
+From 0f8c0f8a7782178c40157b2feb6a532493cbadd3 Mon Sep 17 00:00:00 2001
+From: Michal Suchanek <msuchanek@suse.de>
+Date: Thu, 3 Oct 2019 12:13:55 +0200
+Subject: soundwire: depend on ACPI || OF
+
+From: Michal Suchanek <msuchanek@suse.de>
+
+commit 0f8c0f8a7782178c40157b2feb6a532493cbadd3 upstream.
+
+Now devicetree is supported for probing soundwire as well.
+
+On platforms built with !ACPI !OF (ie s390x) the device still cannot be
+probed and gives a build warning.
+
+Cc: stable@vger.kernel.org
+Fixes: a2e484585ad3 ("soundwire: core: add device tree support for slave devices")
+Signed-off-by: Michal Suchanek <msuchanek@suse.de>
+Link: https://lore.kernel.org/r/0b89b4ea16a93f523105c81a2f718b0cd7ec66f2.1570097621.git.msuchanek@suse.de
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+diff --git a/drivers/soundwire/Kconfig b/drivers/soundwire/Kconfig
+index c73bfbaa2659..c8c80df090d1 100644
+--- a/drivers/soundwire/Kconfig
++++ b/drivers/soundwire/Kconfig
+@@ -5,7 +5,7 @@
+
+ menuconfig SOUNDWIRE
+ tristate "SoundWire support"
+- depends on ACPI
++ depends on ACPI || OF
+ help
+ SoundWire is a 2-Pin interface with data and clock line ratified
+ by the MIPI Alliance. SoundWire is used for transporting data
--- /dev/null
+From 52eb063d153ac310058fbaa91577a72c0e7a7169 Mon Sep 17 00:00:00 2001
+From: Michal Suchanek <msuchanek@suse.de>
+Date: Thu, 3 Oct 2019 12:13:54 +0200
+Subject: soundwire: depend on ACPI
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Michal Suchanek <msuchanek@suse.de>
+
+commit 52eb063d153ac310058fbaa91577a72c0e7a7169 upstream.
+
+The device cannot be probed on !ACPI and gives this warning:
+
+drivers/soundwire/slave.c:16:12: warning: ‘sdw_slave_add’ defined but
+not used [-Wunused-function]
+ static int sdw_slave_add(struct sdw_bus *bus,
+ ^~~~~~~~~~~~~
+
+Cc: stable@vger.kernel.org
+Fixes: 7c3cd189b86d ("soundwire: Add Master registration")
+Signed-off-by: Michal Suchanek <msuchanek@suse.de>
+Link: https://lore.kernel.org/r/bd685232ea511251eeb9554172f1524eabf9a46e.1570097621.git.msuchanek@suse.de
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/soundwire/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/soundwire/Kconfig
++++ b/drivers/soundwire/Kconfig
+@@ -5,6 +5,7 @@
+
+ menuconfig SOUNDWIRE
+ tristate "SoundWire support"
++ depends on ACPI
+ help
+ SoundWire is a 2-Pin interface with data and clock line ratified
+ by the MIPI Alliance. SoundWire is used for transporting data
--- /dev/null
+From 4a6a6f5c4aeedb72db871d60bfcca89835f317aa Mon Sep 17 00:00:00 2001
+From: Shuah Khan <skhan@linuxfoundation.org>
+Date: Thu, 26 Sep 2019 19:16:41 -0600
+Subject: tools: gpio: Use !building_out_of_srctree to determine srctree
+
+From: Shuah Khan <skhan@linuxfoundation.org>
+
+commit 4a6a6f5c4aeedb72db871d60bfcca89835f317aa upstream.
+
+make TARGETS=gpio kselftest fails with:
+
+Makefile:23: tools/build/Makefile.include: No such file or directory
+
+When the gpio tool make is invoked from tools Makefile, srctree is
+cleared and the current logic check for srctree equals to empty
+string to determine srctree location from CURDIR.
+
+When the build in invoked from selftests/gpio Makefile, the srctree
+is set to "." and the same logic used for srctree equals to empty is
+needed to determine srctree.
+
+Check building_out_of_srctree undefined as the condition for both
+cases to fix "make TARGETS=gpio kselftest" build failure.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/gpio/Makefile | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/tools/gpio/Makefile
++++ b/tools/gpio/Makefile
+@@ -3,7 +3,11 @@ include ../scripts/Makefile.include
+
+ bindir ?= /usr/bin
+
+-ifeq ($(srctree),)
++# This will work when gpio is built in tools env. where srctree
++# isn't set and when invoked from selftests build, where srctree
++# is set to ".". building_out_of_srctree is undefined for in srctree
++# builds
++ifndef building_out_of_srctree
+ srctree := $(patsubst %/,%,$(dir $(CURDIR)))
+ srctree := $(patsubst %/,%,$(dir $(srctree)))
+ endif
--- /dev/null
+From fe6f85ca121e9c74e7490fe66b0c5aae38e332c3 Mon Sep 17 00:00:00 2001
+From: Jan Beulich <jbeulich@suse.com>
+Date: Tue, 29 Oct 2019 10:34:19 +0100
+Subject: x86/apic/32: Avoid bogus LDR warnings
+
+From: Jan Beulich <jbeulich@suse.com>
+
+commit fe6f85ca121e9c74e7490fe66b0c5aae38e332c3 upstream.
+
+The removal of the LDR initialization in the bigsmp_32 APIC code unearthed
+a problem in setup_local_APIC().
+
+The code checks unconditionally for a mismatch of the logical APIC id by
+comparing the early APIC id which was initialized in get_smp_config() with
+the actual LDR value in the APIC.
+
+Due to the removal of the bogus LDR initialization the check now can
+trigger on bigsmp_32 APIC systems emitting a warning for every booting
+CPU. This is of course a false positive because the APIC is not using
+logical destination mode.
+
+Restrict the check and the possibly resulting fixup to systems which are
+actually using the APIC in logical destination mode.
+
+[ tglx: Massaged changelog and added Cc stable ]
+
+Fixes: bae3a8d3308 ("x86/apic: Do not initialize LDR and DFR for bigsmp")
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/666d8f91-b5a8-1afd-7add-821e72a35f03@suse.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/apic/apic.c | 28 +++++++++++++++-------------
+ 1 file changed, 15 insertions(+), 13 deletions(-)
+
+--- a/arch/x86/kernel/apic/apic.c
++++ b/arch/x86/kernel/apic/apic.c
+@@ -1573,9 +1573,6 @@ static void setup_local_APIC(void)
+ {
+ int cpu = smp_processor_id();
+ unsigned int value;
+-#ifdef CONFIG_X86_32
+- int logical_apicid, ldr_apicid;
+-#endif
+
+
+ if (disable_apic) {
+@@ -1616,16 +1613,21 @@ static void setup_local_APIC(void)
+ apic->init_apic_ldr();
+
+ #ifdef CONFIG_X86_32
+- /*
+- * APIC LDR is initialized. If logical_apicid mapping was
+- * initialized during get_smp_config(), make sure it matches the
+- * actual value.
+- */
+- logical_apicid = early_per_cpu(x86_cpu_to_logical_apicid, cpu);
+- ldr_apicid = GET_APIC_LOGICAL_ID(apic_read(APIC_LDR));
+- WARN_ON(logical_apicid != BAD_APICID && logical_apicid != ldr_apicid);
+- /* always use the value from LDR */
+- early_per_cpu(x86_cpu_to_logical_apicid, cpu) = ldr_apicid;
++ if (apic->dest_logical) {
++ int logical_apicid, ldr_apicid;
++
++ /*
++ * APIC LDR is initialized. If logical_apicid mapping was
++ * initialized during get_smp_config(), make sure it matches
++ * the actual value.
++ */
++ logical_apicid = early_per_cpu(x86_cpu_to_logical_apicid, cpu);
++ ldr_apicid = GET_APIC_LOGICAL_ID(apic_read(APIC_LDR));
++ if (logical_apicid != BAD_APICID)
++ WARN_ON(logical_apicid != ldr_apicid);
++ /* Always use the value from LDR. */
++ early_per_cpu(x86_cpu_to_logical_apicid, cpu) = ldr_apicid;
++ }
+ #endif
+
+ /*
--- /dev/null
+From e361362b08cab1098b64b0e5fd8c879f086b3f46 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Wed, 23 Oct 2019 20:05:49 +0200
+Subject: x86/dumpstack/64: Don't evaluate exception stacks before setup
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit e361362b08cab1098b64b0e5fd8c879f086b3f46 upstream.
+
+Cyrill reported the following crash:
+
+ BUG: unable to handle page fault for address: 0000000000001ff0
+ #PF: supervisor read access in kernel mode
+ RIP: 0010:get_stack_info+0xb3/0x148
+
+It turns out that if the stack tracer is invoked before the exception stack
+mappings are initialized in_exception_stack() can erroneously classify an
+invalid address as an address inside of an exception stack:
+
+ begin = this_cpu_read(cea_exception_stacks); <- 0
+ end = begin + sizeof(exception stacks);
+
+i.e. any address between 0 and end will be considered as exception stack
+address and the subsequent code will then try to derefence the resulting
+stack frame at a non mapped address.
+
+ end = begin + (unsigned long)ep->size;
+ ==> end = 0x2000
+
+ regs = (struct pt_regs *)end - 1;
+ ==> regs = 0x2000 - sizeof(struct pt_regs *) = 0x1ff0
+
+ info->next_sp = (unsigned long *)regs->sp;
+ ==> Crashes due to accessing 0x1ff0
+
+Prevent this by checking the validity of the cea_exception_stack base
+address and bailing out if it is zero.
+
+Fixes: afcd21dad88b ("x86/dumpstack/64: Use cpu_entry_area instead of orig_ist")
+Reported-by: Cyrill Gorcunov <gorcunov@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Cyrill Gorcunov <gorcunov@gmail.com>
+Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1910231950590.1852@nanos.tec.linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/dumpstack_64.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/arch/x86/kernel/dumpstack_64.c
++++ b/arch/x86/kernel/dumpstack_64.c
+@@ -94,6 +94,13 @@ static bool in_exception_stack(unsigned
+ BUILD_BUG_ON(N_EXCEPTION_STACKS != 6);
+
+ begin = (unsigned long)__this_cpu_read(cea_exception_stacks);
++ /*
++ * Handle the case where stack trace is collected _before_
++ * cea_exception_stacks had been initialized.
++ */
++ if (!begin)
++ return false;
++
+ end = begin + sizeof(struct cea_exception_stacks);
+ /* Bail if @stack is outside the exception stack area. */
+ if (stk < begin || stk >= end)
projects / thirdparty / kernel / stable-queue.git / commitdiff
