--- /dev/null
+From dbb58e291cd47e594b64293bd91a4ce40626513c Mon Sep 17 00:00:00 2001
+From: Adam Ford <aford173@gmail.com>
+Date: Tue, 2 Apr 2019 14:19:08 -0500
+Subject: ARM: dts: imx6q-logicpd: Reduce inrush current on start
+
+From: Adam Ford <aford173@gmail.com>
+
+commit dbb58e291cd47e594b64293bd91a4ce40626513c upstream.
+
+The main 3.3V regulator sources a series of additional regulators.
+This patch adds a small delay, so when the 3.3V regulator comes
+on it delays a bit before the subsequent regulators can come on.
+This reduces the inrush current a bit on the external DC power
+supply to help prevent a situation where the sourcing power supply
+cannot source enough current and overloads and the kit fails to
+start.
+
+Fixes: 1c207f911fe9 ("ARM: dts: imx: Add support for Logic PD i.MX6QD EVM")
+Signed-off-by: Adam Ford <aford173@gmail.com>
+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 | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi
++++ b/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi
+@@ -100,6 +100,7 @@
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio1 26 GPIO_ACTIVE_HIGH>;
++ startup-delay-us = <70000>;
+ enable-active-high;
+ regulator-always-on;
+ };
--- /dev/null
+From 7aedca875074b33795bc77066b325898b1eb8032 Mon Sep 17 00:00:00 2001
+From: Adam Ford <aford173@gmail.com>
+Date: Tue, 2 Apr 2019 14:32:04 -0500
+Subject: ARM: dts: imx6q-logicpd: Reduce inrush current on USBH1
+
+From: Adam Ford <aford173@gmail.com>
+
+commit 7aedca875074b33795bc77066b325898b1eb8032 upstream.
+
+Some USB peripherals draw more power, and the sourcing regulator
+take a little time to turn on. This patch fixes an issue where
+some devices occasionally do not get detected, because the power
+isn't quite ready when communication starts, so we add a bit
+of a delay.
+
+Fixes: 1c207f911fe9 ("ARM: dts: imx: Add support for Logic PD i.MX6QD EVM")
+Signed-off-by: Adam Ford <aford173@gmail.com>
+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 | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi
++++ b/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi
+@@ -88,6 +88,7 @@
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
++ startup-delay-us = <70000>;
+ enable-active-high;
+ };
+
--- /dev/null
+From c6110222c6f49ea68169f353565eb865488a8619 Mon Sep 17 00:00:00 2001
+From: Daniel Borkmann <daniel@iogearbox.net>
+Date: Tue, 14 May 2019 01:18:55 +0200
+Subject: bpf: add map_lookup_elem_sys_only for lookups from syscall side
+
+From: Daniel Borkmann <daniel@iogearbox.net>
+
+commit c6110222c6f49ea68169f353565eb865488a8619 upstream.
+
+Add a callback map_lookup_elem_sys_only() that map implementations
+could use over map_lookup_elem() from system call side in case the
+map implementation needs to handle the latter differently than from
+the BPF data path. If map_lookup_elem_sys_only() is set, this will
+be preferred pick for map lookups out of user space. This hook is
+used in a follow-up fix for LRU map, but once development window
+opens, we can convert other map types from map_lookup_elem() (here,
+the one called upon BPF_MAP_LOOKUP_ELEM cmd is meant) over to use
+the callback to simplify and clean up the latter.
+
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Acked-by: Martin KaFai Lau <kafai@fb.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/bpf.h | 1 +
+ kernel/bpf/syscall.c | 5 ++++-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+--- a/include/linux/bpf.h
++++ b/include/linux/bpf.h
+@@ -36,6 +36,7 @@ struct bpf_map_ops {
+ void (*map_free)(struct bpf_map *map);
+ int (*map_get_next_key)(struct bpf_map *map, void *key, void *next_key);
+ void (*map_release_uref)(struct bpf_map *map);
++ void *(*map_lookup_elem_sys_only)(struct bpf_map *map, void *key);
+
+ /* funcs callable from userspace and from eBPF programs */
+ void *(*map_lookup_elem)(struct bpf_map *map, void *key);
+--- a/kernel/bpf/syscall.c
++++ b/kernel/bpf/syscall.c
+@@ -773,7 +773,10 @@ static int map_lookup_elem(union bpf_att
+ err = map->ops->map_peek_elem(map, value);
+ } else {
+ rcu_read_lock();
+- ptr = map->ops->map_lookup_elem(map, key);
++ if (map->ops->map_lookup_elem_sys_only)
++ ptr = map->ops->map_lookup_elem_sys_only(map, key);
++ else
++ ptr = map->ops->map_lookup_elem(map, key);
+ if (IS_ERR(ptr)) {
+ err = PTR_ERR(ptr);
+ } else if (!ptr) {
--- /dev/null
+From 50b045a8c0ccf44f76640ac3eea8d80ca53979a3 Mon Sep 17 00:00:00 2001
+From: Daniel Borkmann <daniel@iogearbox.net>
+Date: Tue, 14 May 2019 01:18:56 +0200
+Subject: bpf, lru: avoid messing with eviction heuristics upon syscall lookup
+
+From: Daniel Borkmann <daniel@iogearbox.net>
+
+commit 50b045a8c0ccf44f76640ac3eea8d80ca53979a3 upstream.
+
+One of the biggest issues we face right now with picking LRU map over
+regular hash table is that a map walk out of user space, for example,
+to just dump the existing entries or to remove certain ones, will
+completely mess up LRU eviction heuristics and wrong entries such
+as just created ones will get evicted instead. The reason for this
+is that we mark an entry as "in use" via bpf_lru_node_set_ref() from
+system call lookup side as well. Thus upon walk, all entries are
+being marked, so information of actual least recently used ones
+are "lost".
+
+In case of Cilium where it can be used (besides others) as a BPF
+based connection tracker, this current behavior causes disruption
+upon control plane changes that need to walk the map from user space
+to evict certain entries. Discussion result from bpfconf [0] was that
+we should simply just remove marking from system call side as no
+good use case could be found where it's actually needed there.
+Therefore this patch removes marking for regular LRU and per-CPU
+flavor. If there ever should be a need in future, the behavior could
+be selected via map creation flag, but due to mentioned reason we
+avoid this here.
+
+ [0] http://vger.kernel.org/bpfconf.html
+
+Fixes: 29ba732acbee ("bpf: Add BPF_MAP_TYPE_LRU_HASH")
+Fixes: 8f8449384ec3 ("bpf: Add BPF_MAP_TYPE_LRU_PERCPU_HASH")
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Acked-by: Martin KaFai Lau <kafai@fb.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/bpf/hashtab.c | 23 ++++++++++++++++++-----
+ 1 file changed, 18 insertions(+), 5 deletions(-)
+
+--- a/kernel/bpf/hashtab.c
++++ b/kernel/bpf/hashtab.c
+@@ -527,18 +527,30 @@ static u32 htab_map_gen_lookup(struct bp
+ return insn - insn_buf;
+ }
+
+-static void *htab_lru_map_lookup_elem(struct bpf_map *map, void *key)
++static __always_inline void *__htab_lru_map_lookup_elem(struct bpf_map *map,
++ void *key, const bool mark)
+ {
+ struct htab_elem *l = __htab_map_lookup_elem(map, key);
+
+ if (l) {
+- bpf_lru_node_set_ref(&l->lru_node);
++ if (mark)
++ bpf_lru_node_set_ref(&l->lru_node);
+ return l->key + round_up(map->key_size, 8);
+ }
+
+ return NULL;
+ }
+
++static void *htab_lru_map_lookup_elem(struct bpf_map *map, void *key)
++{
++ return __htab_lru_map_lookup_elem(map, key, true);
++}
++
++static void *htab_lru_map_lookup_elem_sys(struct bpf_map *map, void *key)
++{
++ return __htab_lru_map_lookup_elem(map, key, false);
++}
++
+ static u32 htab_lru_map_gen_lookup(struct bpf_map *map,
+ struct bpf_insn *insn_buf)
+ {
+@@ -1250,6 +1262,7 @@ const struct bpf_map_ops htab_lru_map_op
+ .map_free = htab_map_free,
+ .map_get_next_key = htab_map_get_next_key,
+ .map_lookup_elem = htab_lru_map_lookup_elem,
++ .map_lookup_elem_sys_only = htab_lru_map_lookup_elem_sys,
+ .map_update_elem = htab_lru_map_update_elem,
+ .map_delete_elem = htab_lru_map_delete_elem,
+ .map_gen_lookup = htab_lru_map_gen_lookup,
+@@ -1281,7 +1294,6 @@ static void *htab_lru_percpu_map_lookup_
+
+ int bpf_percpu_hash_copy(struct bpf_map *map, void *key, void *value)
+ {
+- struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
+ struct htab_elem *l;
+ void __percpu *pptr;
+ int ret = -ENOENT;
+@@ -1297,8 +1309,9 @@ int bpf_percpu_hash_copy(struct bpf_map
+ l = __htab_map_lookup_elem(map, key);
+ if (!l)
+ goto out;
+- if (htab_is_lru(htab))
+- bpf_lru_node_set_ref(&l->lru_node);
++ /* We do not mark LRU map element here in order to not mess up
++ * eviction heuristics when user space does a map walk.
++ */
+ pptr = htab_elem_get_ptr(l, map->key_size);
+ for_each_possible_cpu(cpu) {
+ bpf_long_memcpy(value + off,
--- /dev/null
+From e547ff3f803e779a3898f1f48447b29f43c54085 Mon Sep 17 00:00:00 2001
+From: Chenbo Feng <fengc@google.com>
+Date: Tue, 14 May 2019 19:42:57 -0700
+Subject: bpf: relax inode permission check for retrieving bpf program
+
+From: Chenbo Feng <fengc@google.com>
+
+commit e547ff3f803e779a3898f1f48447b29f43c54085 upstream.
+
+For iptable module to load a bpf program from a pinned location, it
+only retrieve a loaded program and cannot change the program content so
+requiring a write permission for it might not be necessary.
+Also when adding or removing an unrelated iptable rule, it might need to
+flush and reload the xt_bpf related rules as well and triggers the inode
+permission check. It might be better to remove the write premission
+check for the inode so we won't need to grant write access to all the
+processes that flush and restore iptables rules.
+
+Signed-off-by: Chenbo Feng <fengc@google.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/bpf/inode.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/bpf/inode.c
++++ b/kernel/bpf/inode.c
+@@ -518,7 +518,7 @@ out:
+ static struct bpf_prog *__get_prog_inode(struct inode *inode, enum bpf_prog_type type)
+ {
+ struct bpf_prog *prog;
+- int ret = inode_permission(inode, MAY_READ | MAY_WRITE);
++ int ret = inode_permission(inode, MAY_READ);
+ if (ret)
+ return ERR_PTR(ret);
+
--- /dev/null
+From 10995c0491204c861948c9850939a7f4e90760a4 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Mon, 18 Mar 2019 10:48:19 +0800
+Subject: btrfs: reloc: Fix NULL pointer dereference due to expanded reloc_root lifespan
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit 10995c0491204c861948c9850939a7f4e90760a4 upstream.
+
+Commit d2311e698578 ("btrfs: relocation: Delay reloc tree deletion after
+merge_reloc_roots()") expands the life span of root->reloc_root.
+
+This breaks certain checs of fs_info->reloc_ctl. Before that commit, if
+we have a root with valid reloc_root, then it's ensured to have
+fs_info->reloc_ctl.
+
+But now since reloc_root doesn't always mean a valid fs_info->reloc_ctl,
+such check is unreliable and can cause the following NULL pointer
+dereference:
+
+ BUG: unable to handle kernel NULL pointer dereference at 00000000000005c1
+ IP: btrfs_reloc_pre_snapshot+0x20/0x50 [btrfs]
+ PGD 0 P4D 0
+ Oops: 0000 [#1] SMP PTI
+ CPU: 0 PID: 10379 Comm: snapperd Not tainted
+ Call Trace:
+ create_pending_snapshot+0xd7/0xfc0 [btrfs]
+ create_pending_snapshots+0x8e/0xb0 [btrfs]
+ btrfs_commit_transaction+0x2ac/0x8f0 [btrfs]
+ btrfs_mksubvol+0x561/0x570 [btrfs]
+ btrfs_ioctl_snap_create_transid+0x189/0x190 [btrfs]
+ btrfs_ioctl_snap_create_v2+0x102/0x150 [btrfs]
+ btrfs_ioctl+0x5c9/0x1e60 [btrfs]
+ do_vfs_ioctl+0x90/0x5f0
+ SyS_ioctl+0x74/0x80
+ do_syscall_64+0x7b/0x150
+ entry_SYSCALL_64_after_hwframe+0x3d/0xa2
+ RIP: 0033:0x7fd7cdab8467
+
+Fix it by explicitly checking fs_info->reloc_ctl other than using the
+implied root->reloc_root.
+
+Fixes: d2311e698578 ("btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots")
+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/relocation.c | 12 +++++-------
+ 1 file changed, 5 insertions(+), 7 deletions(-)
+
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -4667,14 +4667,12 @@ int btrfs_reloc_cow_block(struct btrfs_t
+ void btrfs_reloc_pre_snapshot(struct btrfs_pending_snapshot *pending,
+ u64 *bytes_to_reserve)
+ {
+- struct btrfs_root *root;
+- struct reloc_control *rc;
++ struct btrfs_root *root = pending->root;
++ struct reloc_control *rc = root->fs_info->reloc_ctl;
+
+- root = pending->root;
+- if (!root->reloc_root)
++ if (!root->reloc_root || !rc)
+ return;
+
+- rc = root->fs_info->reloc_ctl;
+ if (!rc->merge_reloc_tree)
+ return;
+
+@@ -4703,10 +4701,10 @@ int btrfs_reloc_post_snapshot(struct btr
+ struct btrfs_root *root = pending->root;
+ struct btrfs_root *reloc_root;
+ struct btrfs_root *new_root;
+- struct reloc_control *rc;
++ struct reloc_control *rc = root->fs_info->reloc_ctl;
+ int ret;
+
+- if (!root->reloc_root)
++ if (!root->reloc_root || !rc)
+ return 0;
+
+ rc = root->fs_info->reloc_ctl;
--- /dev/null
+From 51b86f9a8d1c4bb4e3862ee4b4c5f46072f7520d Mon Sep 17 00:00:00 2001
+From: Michael Lass <bevan@bi-co.net>
+Date: Tue, 21 May 2019 21:58:07 +0200
+Subject: dm: make sure to obey max_io_len_target_boundary
+
+From: Michael Lass <bevan@bi-co.net>
+
+commit 51b86f9a8d1c4bb4e3862ee4b4c5f46072f7520d upstream.
+
+Commit 61697a6abd24 ("dm: eliminate 'split_discard_bios' flag from DM
+target interface") incorrectly removed code from
+__send_changing_extent_only() that is required to impose a per-target IO
+boundary on IO that exceeds max_io_len_target_boundary(). Otherwise
+"special" IO (e.g. DISCARD, WRITE SAME, WRITE ZEROES) can write beyond
+where allowed.
+
+Fix this by restoring the max_io_len_target_boundary() limit in
+__send_changing_extent_only()
+
+Fixes: 61697a6abd24 ("dm: eliminate 'split_discard_bios' flag from DM target interface")
+Cc: stable@vger.kernel.org # 5.1+
+Signed-off-by: Michael Lass <bevan@bi-co.net>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm.c
++++ b/drivers/md/dm.c
+@@ -1467,7 +1467,7 @@ static unsigned get_num_write_zeroes_bio
+ static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *ti,
+ unsigned num_bios)
+ {
+- unsigned len = ci->sector_count;
++ unsigned len;
+
+ /*
+ * Even though the device advertised support for this type of
+@@ -1478,6 +1478,8 @@ static int __send_changing_extent_only(s
+ if (!num_bios)
+ return -EOPNOTSUPP;
+
++ len = min((sector_t)ci->sector_count, max_io_len_target_boundary(ci->sector, ti));
++
+ __send_duplicate_bios(ci, ti, num_bios, &len);
+
+ ci->sector += len;
--- /dev/null
+From 941acd566b1807b291bbdca31cc5158e26ffcf83 Mon Sep 17 00:00:00 2001
+From: "Angus Ainslie (Purism)" <angus@akkea.ca>
+Date: Fri, 29 Mar 2019 08:21:29 -0700
+Subject: dmaengine: imx-sdma: Only check ratio on parts that support 1:1
+
+From: Angus Ainslie (Purism) <angus@akkea.ca>
+
+commit 941acd566b1807b291bbdca31cc5158e26ffcf83 upstream.
+
+On imx8mq B0 chip, AHB/SDMA clock ratio 2:1 can't be supported,
+since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach
+to 500Mhz, so use 1:1 instead.
+
+To limit this change to the imx8mq for now this patch also adds an
+im8mq-sdma compatible string.
+
+Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
+Acked-by: Robin Gong <yibin.gong@nxp.com>
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Cc: Richard Leitner <richard.leitner@skidata.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dma/imx-sdma.c | 15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+--- a/drivers/dma/imx-sdma.c
++++ b/drivers/dma/imx-sdma.c
+@@ -419,6 +419,7 @@ struct sdma_driver_data {
+ int chnenbl0;
+ int num_events;
+ struct sdma_script_start_addrs *script_addrs;
++ bool check_ratio;
+ };
+
+ struct sdma_engine {
+@@ -557,6 +558,13 @@ static struct sdma_driver_data sdma_imx7
+ .script_addrs = &sdma_script_imx7d,
+ };
+
++static struct sdma_driver_data sdma_imx8mq = {
++ .chnenbl0 = SDMA_CHNENBL0_IMX35,
++ .num_events = 48,
++ .script_addrs = &sdma_script_imx7d,
++ .check_ratio = 1,
++};
++
+ static const struct platform_device_id sdma_devtypes[] = {
+ {
+ .name = "imx25-sdma",
+@@ -580,6 +588,9 @@ static const struct platform_device_id s
+ .name = "imx7d-sdma",
+ .driver_data = (unsigned long)&sdma_imx7d,
+ }, {
++ .name = "imx8mq-sdma",
++ .driver_data = (unsigned long)&sdma_imx8mq,
++ }, {
+ /* sentinel */
+ }
+ };
+@@ -593,6 +604,7 @@ static const struct of_device_id sdma_dt
+ { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, },
+ { .compatible = "fsl,imx25-sdma", .data = &sdma_imx25, },
+ { .compatible = "fsl,imx7d-sdma", .data = &sdma_imx7d, },
++ { .compatible = "fsl,imx8mq-sdma", .data = &sdma_imx8mq, },
+ { /* sentinel */ }
+ };
+ MODULE_DEVICE_TABLE(of, sdma_dt_ids);
+@@ -1852,7 +1864,8 @@ static int sdma_init(struct sdma_engine
+ if (ret)
+ goto disable_clk_ipg;
+
+- if (clk_get_rate(sdma->clk_ahb) == clk_get_rate(sdma->clk_ipg))
++ if (sdma->drvdata->check_ratio &&
++ (clk_get_rate(sdma->clk_ahb) == clk_get_rate(sdma->clk_ipg)))
+ sdma->clk_ratio = 1;
+
+ /* Be sure SDMA has not started yet */
--- /dev/null
+From 0b777eee88d712256ba8232a9429edb17c4f9ceb Mon Sep 17 00:00:00 2001
+From: John Garry <john.garry@huawei.com>
+Date: Thu, 28 Mar 2019 18:08:05 +0800
+Subject: driver core: Postpone DMA tear-down until after devres release for probe failure
+
+From: John Garry <john.garry@huawei.com>
+
+commit 0b777eee88d712256ba8232a9429edb17c4f9ceb upstream.
+
+In commit 376991db4b64 ("driver core: Postpone DMA tear-down until after
+devres release"), we changed the ordering of tearing down the device DMA
+ops and releasing all the device's resources; this was because the DMA ops
+should be maintained until we release the device's managed DMA memories.
+
+However, we have seen another crash on an arm64 system when a
+device driver probe fails:
+
+ hisi_sas_v3_hw 0000:74:02.0: Adding to iommu group 2
+ scsi host1: hisi_sas_v3_hw
+ BUG: Bad page state in process swapper/0 pfn:313f5
+ page:ffff7e0000c4fd40 count:1 mapcount:0
+ mapping:0000000000000000 index:0x0
+ flags: 0xfffe00000001000(reserved)
+ raw: 0fffe00000001000 ffff7e0000c4fd48 ffff7e0000c4fd48
+0000000000000000
+ raw: 0000000000000000 0000000000000000 00000001ffffffff
+0000000000000000
+ page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
+ bad because of flags: 0x1000(reserved)
+ Modules linked in:
+ CPU: 49 PID: 1 Comm: swapper/0 Not tainted
+5.1.0-rc1-43081-g22d97fd-dirty #1433
+ Hardware name: Huawei D06/D06, BIOS Hisilicon D06 UEFI
+RC0 - V1.12.01 01/29/2019
+ Call trace:
+ dump_backtrace+0x0/0x118
+ show_stack+0x14/0x1c
+ dump_stack+0xa4/0xc8
+ bad_page+0xe4/0x13c
+ free_pages_check_bad+0x4c/0xc0
+ __free_pages_ok+0x30c/0x340
+ __free_pages+0x30/0x44
+ __dma_direct_free_pages+0x30/0x38
+ dma_direct_free+0x24/0x38
+ dma_free_attrs+0x9c/0xd8
+ dmam_release+0x20/0x28
+ release_nodes+0x17c/0x220
+ devres_release_all+0x34/0x54
+ really_probe+0xc4/0x2c8
+ driver_probe_device+0x58/0xfc
+ device_driver_attach+0x68/0x70
+ __driver_attach+0x94/0xdc
+ bus_for_each_dev+0x5c/0xb4
+ driver_attach+0x20/0x28
+ bus_add_driver+0x14c/0x200
+ driver_register+0x6c/0x124
+ __pci_register_driver+0x48/0x50
+ sas_v3_pci_driver_init+0x20/0x28
+ do_one_initcall+0x40/0x25c
+ kernel_init_freeable+0x2b8/0x3c0
+ kernel_init+0x10/0x100
+ ret_from_fork+0x10/0x18
+ Disabling lock debugging due to kernel taint
+ BUG: Bad page state in process swapper/0 pfn:313f6
+ page:ffff7e0000c4fd80 count:1 mapcount:0
+mapping:0000000000000000 index:0x0
+[ 89.322983] flags: 0xfffe00000001000(reserved)
+ raw: 0fffe00000001000 ffff7e0000c4fd88 ffff7e0000c4fd88
+0000000000000000
+ raw: 0000000000000000 0000000000000000 00000001ffffffff
+0000000000000000
+
+The crash occurs for the same reason.
+
+In this case, on the really_probe() failure path, we are still clearing
+the DMA ops prior to releasing the device's managed memories.
+
+This patch fixes this issue by reordering the DMA ops teardown and the
+call to devres_release_all() on the failure path.
+
+Reported-by: Xiang Chen <chenxiang66@hisilicon.com>
+Tested-by: Xiang Chen <chenxiang66@hisilicon.com>
+Signed-off-by: John Garry <john.garry@huawei.com>
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/base/dd.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/base/dd.c
++++ b/drivers/base/dd.c
+@@ -490,7 +490,7 @@ re_probe:
+ if (dev->bus->dma_configure) {
+ ret = dev->bus->dma_configure(dev);
+ if (ret)
+- goto dma_failed;
++ goto probe_failed;
+ }
+
+ if (driver_sysfs_add(dev)) {
+@@ -546,14 +546,13 @@ re_probe:
+ goto done;
+
+ probe_failed:
+- arch_teardown_dma_ops(dev);
+-dma_failed:
+ if (dev->bus)
+ blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
+ BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
+ pinctrl_bind_failed:
+ device_links_no_driver(dev);
+ devres_release_all(dev);
++ arch_teardown_dma_ops(dev);
+ driver_sysfs_remove(dev);
+ dev->driver = NULL;
+ dev_set_drvdata(dev, NULL);
--- /dev/null
+From b2176a1dfb518d870ee073445d27055fea64dfb8 Mon Sep 17 00:00:00 2001
+From: Nigel Croxon <ncroxon@redhat.com>
+Date: Tue, 16 Apr 2019 09:50:09 -0700
+Subject: md/raid: raid5 preserve the writeback action after the parity check
+
+From: Nigel Croxon <ncroxon@redhat.com>
+
+commit b2176a1dfb518d870ee073445d27055fea64dfb8 upstream.
+
+The problem is that any 'uptodate' vs 'disks' check is not precise
+in this path. Put a "WARN_ON(!test_bit(R5_UPTODATE, &dev->flags)" on the
+device that might try to kick off writes and then skip the action.
+Better to prevent the raid driver from taking unexpected action *and* keep
+the system alive vs killing the machine with BUG_ON.
+
+Note: fixed warning reported by kbuild test robot <lkp@intel.com>
+
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid5.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -4187,7 +4187,7 @@ static void handle_parity_checks6(struct
+ /* now write out any block on a failed drive,
+ * or P or Q if they were recomputed
+ */
+- BUG_ON(s->uptodate < disks - 1); /* We don't need Q to recover */
++ dev = NULL;
+ if (s->failed == 2) {
+ dev = &sh->dev[s->failed_num[1]];
+ s->locked++;
+@@ -4212,6 +4212,14 @@ static void handle_parity_checks6(struct
+ set_bit(R5_LOCKED, &dev->flags);
+ set_bit(R5_Wantwrite, &dev->flags);
+ }
++ if (WARN_ONCE(dev && !test_bit(R5_UPTODATE, &dev->flags),
++ "%s: disk%td not up to date\n",
++ mdname(conf->mddev),
++ dev - (struct r5dev *) &sh->dev)) {
++ clear_bit(R5_LOCKED, &dev->flags);
++ clear_bit(R5_Wantwrite, &dev->flags);
++ s->locked--;
++ }
+ clear_bit(STRIPE_DEGRADED, &sh->state);
+
+ set_bit(STRIPE_INSYNC, &sh->state);
--- /dev/null
+From a25d8c327bb41742dbd59f8c545f59f3b9c39983 Mon Sep 17 00:00:00 2001
+From: Song Liu <songliubraving@fb.com>
+Date: Tue, 16 Apr 2019 09:34:21 -0700
+Subject: Revert "Don't jump to compute_result state from check_result state"
+
+From: Song Liu <songliubraving@fb.com>
+
+commit a25d8c327bb41742dbd59f8c545f59f3b9c39983 upstream.
+
+This reverts commit 4f4fd7c5798bbdd5a03a60f6269cf1177fbd11ef.
+
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: Nigel Croxon <ncroxon@redhat.com>
+Cc: Xiao Ni <xni@redhat.com>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid5.c | 19 +++++++++++++++----
+ 1 file changed, 15 insertions(+), 4 deletions(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -4223,15 +4223,26 @@ static void handle_parity_checks6(struct
+ case check_state_check_result:
+ sh->check_state = check_state_idle;
+
+- if (s->failed > 1)
+- break;
+ /* handle a successful check operation, if parity is correct
+ * we are done. Otherwise update the mismatch count and repair
+ * parity if !MD_RECOVERY_CHECK
+ */
+ if (sh->ops.zero_sum_result == 0) {
+- /* Any parity checked was correct */
+- set_bit(STRIPE_INSYNC, &sh->state);
++ /* both parities are correct */
++ if (!s->failed)
++ set_bit(STRIPE_INSYNC, &sh->state);
++ else {
++ /* in contrast to the raid5 case we can validate
++ * parity, but still have a failure to write
++ * back
++ */
++ sh->check_state = check_state_compute_result;
++ /* Returning at this point means that we may go
++ * off and bring p and/or q uptodate again so
++ * we make sure to check zero_sum_result again
++ * to verify if p or q need writeback
++ */
++ }
+ } else {
+ atomic64_add(STRIPE_SECTORS, &conf->mddev->resync_mismatches);
+ if (test_bit(MD_RECOVERY_CHECK, &conf->mddev->recovery)) {
dm-ioctl-fix-hang-in-early-create-error-condition.patch
dm-mpath-always-free-attached_handler_name-in-parse_path.patch
fuse-add-fopen_stream-to-use-stream_open.patch
+dm-make-sure-to-obey-max_io_len_target_boundary.patch
+revert-don-t-jump-to-compute_result-state-from-check_result-state.patch
+md-raid-raid5-preserve-the-writeback-action-after-the-parity-check.patch
+dmaengine-imx-sdma-only-check-ratio-on-parts-that-support-1-1.patch
+driver-core-postpone-dma-tear-down-until-after-devres-release-for-probe-failure.patch
+bpf-relax-inode-permission-check-for-retrieving-bpf-program.patch
+bpf-add-map_lookup_elem_sys_only-for-lookups-from-syscall-side.patch
+bpf-lru-avoid-messing-with-eviction-heuristics-upon-syscall-lookup.patch
+y2038-make-config_64bit_time-unconditional.patch
+btrfs-reloc-fix-null-pointer-dereference-due-to-expanded-reloc_root-lifespan.patch
+arm-dts-imx6q-logicpd-reduce-inrush-current-on-usbh1.patch
+arm-dts-imx6q-logicpd-reduce-inrush-current-on-start.patch
--- /dev/null
+From f3d964673b2f1c5d5c68c77273efcf7103eed03b Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Mon, 29 Apr 2019 15:19:37 +0200
+Subject: y2038: Make CONFIG_64BIT_TIME unconditional
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit f3d964673b2f1c5d5c68c77273efcf7103eed03b upstream.
+
+As Stepan Golosunov points out, there is a small mistake in the
+get_timespec64() function in the kernel. It was originally added under the
+assumption that CONFIG_64BIT_TIME would get enabled on all 32-bit and
+64-bit architectures, but when the conversion was done, it was only turned
+on for 32-bit ones.
+
+The effect is that the get_timespec64() function never clears the upper
+half of the tv_nsec field for 32-bit tasks in compat mode. Clearing this is
+required for POSIX compliant behavior of functions that pass a 'timespec'
+structure with a 64-bit tv_sec and a 32-bit tv_nsec, plus uninitialized
+padding.
+
+The easiest fix for linux-5.1 is to just make the Kconfig symbol
+unconditional, as it was originally intended. As a follow-up, the #ifdef
+CONFIG_64BIT_TIME can be removed completely..
+
+Note: for native 32-bit mode, no change is needed, this works as
+designed and user space should never need to clear the upper 32
+bits of the tv_nsec field, in or out of the kernel.
+
+Fixes: 00bf25d693e7 ("y2038: use time32 syscall names on 32-bit")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Joseph Myers <joseph@codesourcery.com>
+Cc: libc-alpha@sourceware.org
+Cc: linux-api@vger.kernel.org
+Cc: Deepa Dinamani <deepa.kernel@gmail.com>
+Cc: Lukasz Majewski <lukma@denx.de>
+Cc: Stepan Golosunov <stepan@golosunov.pp.ru>
+Link: https://lore.kernel.org/lkml/20190422090710.bmxdhhankurhafxq@sghpc.golosunov.pp.ru/
+Link: https://lkml.kernel.org/r/20190429131951.471701-1-arnd@arndb.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/Kconfig
++++ b/arch/Kconfig
+@@ -764,7 +764,7 @@ config COMPAT_OLD_SIGACTION
+ bool
+
+ config 64BIT_TIME
+- def_bool ARCH_HAS_64BIT_TIME
++ def_bool y
+ help
+ This should be selected by all architectures that need to support
+ new system calls with a 64-bit time_t. This is relevant on all 32-bit
projects / thirdparty / kernel / stable-queue.git / commitdiff
