--- /dev/null
+From fc2266011accd5aeb8ebc335c381991f20e26e33 Mon Sep 17 00:00:00 2001
+From: Fredrik Strupe <fredrik@strupe.net>
+Date: Wed, 8 Apr 2020 13:29:41 +0200
+Subject: arm64: armv8_deprecated: Fix undef_hook mask for thumb setend
+
+From: Fredrik Strupe <fredrik@strupe.net>
+
+commit fc2266011accd5aeb8ebc335c381991f20e26e33 upstream.
+
+For thumb instructions, call_undef_hook() in traps.c first reads a u16,
+and if the u16 indicates a T32 instruction (u16 >= 0xe800), a second
+u16 is read, which then makes up the the lower half-word of a T32
+instruction. For T16 instructions, the second u16 is not read,
+which makes the resulting u32 opcode always have the upper half set to
+0.
+
+However, having the upper half of instr_mask in the undef_hook set to 0
+masks out the upper half of all thumb instructions - both T16 and T32.
+This results in trapped T32 instructions with the lower half-word equal
+to the T16 encoding of setend (b650) being matched, even though the upper
+half-word is not 0000 and thus indicates a T32 opcode.
+
+An example of such a T32 instruction is eaa0b650, which should raise a
+SIGILL since T32 instructions with an eaa prefix are unallocated as per
+Arm ARM, but instead works as a SETEND because the second half-word is set
+to b650.
+
+This patch fixes the issue by extending instr_mask to include the
+upper u32 half, which will still match T16 instructions where the upper
+half is 0, but not T32 instructions.
+
+Fixes: 2d888f48e056 ("arm64: Emulate SETEND for AArch32 tasks")
+Cc: <stable@vger.kernel.org> # 4.0.x-
+Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kernel/armv8_deprecated.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/kernel/armv8_deprecated.c
++++ b/arch/arm64/kernel/armv8_deprecated.c
+@@ -604,7 +604,7 @@ static struct undef_hook setend_hooks[]
+ },
+ {
+ /* Thumb mode */
+- .instr_mask = 0x0000fff7,
++ .instr_mask = 0xfffffff7,
+ .instr_val = 0x0000b650,
+ .pstate_mask = (COMPAT_PSR_T_BIT | COMPAT_PSR_MODE_MASK),
+ .pstate_val = (COMPAT_PSR_T_BIT | COMPAT_PSR_MODE_USR),
--- /dev/null
+From d0a72efac89d1c35ac55197895201b7b94c5e6ef Mon Sep 17 00:00:00 2001
+From: Oliver O'Halloran <oohall@gmail.com>
+Date: Thu, 6 Feb 2020 17:26:21 +1100
+Subject: cpufreq: powernv: Fix use-after-free
+
+From: Oliver O'Halloran <oohall@gmail.com>
+
+commit d0a72efac89d1c35ac55197895201b7b94c5e6ef upstream.
+
+The cpufreq driver has a use-after-free that we can hit if:
+
+a) There's an OCC message pending when the notifier is registered, and
+b) The cpufreq driver fails to register with the core.
+
+When a) occurs the notifier schedules a workqueue item to handle the
+message. The backing work_struct is located on chips[].throttle and
+when b) happens we clean up by freeing the array. Once we get to
+the (now free) queued item and the kernel crashes.
+
+Fixes: c5e29ea7ac14 ("cpufreq: powernv: Fix bugs in powernv_cpufreq_{init/exit}")
+Cc: stable@vger.kernel.org # v4.6+
+Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
+Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20200206062622.28235-1-oohall@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/powernv-cpufreq.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/cpufreq/powernv-cpufreq.c
++++ b/drivers/cpufreq/powernv-cpufreq.c
+@@ -955,6 +955,12 @@ static int init_chip_info(void)
+
+ static inline void clean_chip_info(void)
+ {
++ int i;
++
++ /* flush any pending work items */
++ if (chips)
++ for (i = 0; i < nr_chips; i++)
++ cancel_work_sync(&chips[i].throttle);
+ kfree(chips);
+ }
+
--- /dev/null
+From 75fa601934fda23d2f15bf44b09c2401942d8e15 Mon Sep 17 00:00:00 2001
+From: "Shetty, Harshini X (EXT-Sony Mobile)" <Harshini.X.Shetty@sony.com>
+Date: Tue, 17 Mar 2020 09:15:45 +0000
+Subject: dm verity fec: fix memory leak in verity_fec_dtr
+
+From: Shetty, Harshini X (EXT-Sony Mobile) <Harshini.X.Shetty@sony.com>
+
+commit 75fa601934fda23d2f15bf44b09c2401942d8e15 upstream.
+
+Fix below kmemleak detected in verity_fec_ctr. output_pool is
+allocated for each dm-verity-fec device. But it is not freed when
+dm-table for the verity target is removed. Hence free the output
+mempool in destructor function verity_fec_dtr.
+
+unreferenced object 0xffffffffa574d000 (size 4096):
+ comm "init", pid 1667, jiffies 4294894890 (age 307.168s)
+ hex dump (first 32 bytes):
+ 8e 36 00 98 66 a8 0b 9b 00 00 00 00 00 00 00 00 .6..f...........
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<0000000060e82407>] __kmalloc+0x2b4/0x340
+ [<00000000dd99488f>] mempool_kmalloc+0x18/0x20
+ [<000000002560172b>] mempool_init_node+0x98/0x118
+ [<000000006c3574d2>] mempool_init+0x14/0x20
+ [<0000000008cb266e>] verity_fec_ctr+0x388/0x3b0
+ [<000000000887261b>] verity_ctr+0x87c/0x8d0
+ [<000000002b1e1c62>] dm_table_add_target+0x174/0x348
+ [<000000002ad89eda>] table_load+0xe4/0x328
+ [<000000001f06f5e9>] dm_ctl_ioctl+0x3b4/0x5a0
+ [<00000000bee5fbb7>] do_vfs_ioctl+0x5dc/0x928
+ [<00000000b475b8f5>] __arm64_sys_ioctl+0x70/0x98
+ [<000000005361e2e8>] el0_svc_common+0xa0/0x158
+ [<000000001374818f>] el0_svc_handler+0x6c/0x88
+ [<000000003364e9f4>] el0_svc+0x8/0xc
+ [<000000009d84cec9>] 0xffffffffffffffff
+
+Fixes: a739ff3f543af ("dm verity: add support for forward error correction")
+Depends-on: 6f1c819c219f7 ("dm: convert to bioset_init()/mempool_init()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Harshini Shetty <harshini.x.shetty@sony.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-verity-fec.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/md/dm-verity-fec.c
++++ b/drivers/md/dm-verity-fec.c
+@@ -563,6 +563,7 @@ void verity_fec_dtr(struct dm_verity *v)
+ mempool_destroy(f->rs_pool);
+ mempool_destroy(f->prealloc_pool);
+ mempool_destroy(f->extra_pool);
++ mempool_destroy(f->output_pool);
+ kmem_cache_destroy(f->cache);
+
+ if (f->data_bufio)
--- /dev/null
+From 28936b62e71e41600bab319f262ea9f9b1027629 Mon Sep 17 00:00:00 2001
+From: Qian Cai <cai@lca.pw>
+Date: Fri, 21 Feb 2020 23:32:58 -0500
+Subject: ext4: fix a data race at inode->i_blocks
+
+From: Qian Cai <cai@lca.pw>
+
+commit 28936b62e71e41600bab319f262ea9f9b1027629 upstream.
+
+inode->i_blocks could be accessed concurrently as noticed by KCSAN,
+
+ BUG: KCSAN: data-race in ext4_do_update_inode [ext4] / inode_add_bytes
+
+ write to 0xffff9a00d4b982d0 of 8 bytes by task 22100 on cpu 118:
+ inode_add_bytes+0x65/0xf0
+ __inode_add_bytes at fs/stat.c:689
+ (inlined by) inode_add_bytes at fs/stat.c:702
+ ext4_mb_new_blocks+0x418/0xca0 [ext4]
+ ext4_ext_map_blocks+0x1a6b/0x27b0 [ext4]
+ ext4_map_blocks+0x1a9/0x950 [ext4]
+ _ext4_get_block+0xfc/0x270 [ext4]
+ ext4_get_block_unwritten+0x33/0x50 [ext4]
+ __block_write_begin_int+0x22e/0xae0
+ __block_write_begin+0x39/0x50
+ ext4_write_begin+0x388/0xb50 [ext4]
+ ext4_da_write_begin+0x35f/0x8f0 [ext4]
+ generic_perform_write+0x15d/0x290
+ ext4_buffered_write_iter+0x11f/0x210 [ext4]
+ ext4_file_write_iter+0xce/0x9e0 [ext4]
+ new_sync_write+0x29c/0x3b0
+ __vfs_write+0x92/0xa0
+ vfs_write+0x103/0x260
+ ksys_write+0x9d/0x130
+ __x64_sys_write+0x4c/0x60
+ do_syscall_64+0x91/0xb05
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+ read to 0xffff9a00d4b982d0 of 8 bytes by task 8 on cpu 65:
+ ext4_do_update_inode+0x4a0/0xf60 [ext4]
+ ext4_inode_blocks_set at fs/ext4/inode.c:4815
+ ext4_mark_iloc_dirty+0xaf/0x160 [ext4]
+ ext4_mark_inode_dirty+0x129/0x3e0 [ext4]
+ ext4_convert_unwritten_extents+0x253/0x2d0 [ext4]
+ ext4_convert_unwritten_io_end_vec+0xc5/0x150 [ext4]
+ ext4_end_io_rsv_work+0x22c/0x350 [ext4]
+ process_one_work+0x54f/0xb90
+ worker_thread+0x80/0x5f0
+ kthread+0x1cd/0x1f0
+ ret_from_fork+0x27/0x50
+
+ 4 locks held by kworker/u256:0/8:
+ #0: ffff9a025abc4328 ((wq_completion)ext4-rsv-conversion){+.+.}, at: process_one_work+0x443/0xb90
+ #1: ffffab5a862dbe20 ((work_completion)(&ei->i_rsv_conversion_work)){+.+.}, at: process_one_work+0x443/0xb90
+ #2: ffff9a025a9d0f58 (jbd2_handle){++++}, at: start_this_handle+0x1c1/0x9d0 [jbd2]
+ #3: ffff9a00d4b985d8 (&(&ei->i_raw_lock)->rlock){+.+.}, at: ext4_do_update_inode+0xaa/0xf60 [ext4]
+ irq event stamp: 3009267
+ hardirqs last enabled at (3009267): [<ffffffff980da9b7>] __find_get_block+0x107/0x790
+ hardirqs last disabled at (3009266): [<ffffffff980da8f9>] __find_get_block+0x49/0x790
+ softirqs last enabled at (3009230): [<ffffffff98a0034c>] __do_softirq+0x34c/0x57c
+ softirqs last disabled at (3009223): [<ffffffff97cc67a2>] irq_exit+0xa2/0xc0
+
+ Reported by Kernel Concurrency Sanitizer on:
+ CPU: 65 PID: 8 Comm: kworker/u256:0 Tainted: G L 5.6.0-rc2-next-20200221+ #7
+ Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
+ Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work [ext4]
+
+The plain read is outside of inode->i_lock critical section which
+results in a data race. Fix it by adding READ_ONCE() there.
+
+Link: https://lore.kernel.org/r/20200222043258.2279-1-cai@lca.pw
+Signed-off-by: Qian Cai <cai@lca.pw>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/inode.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/ext4/inode.c
++++ b/fs/ext4/inode.c
+@@ -4754,7 +4754,7 @@ static int ext4_inode_blocks_set(handle_
+ struct ext4_inode_info *ei)
+ {
+ struct inode *inode = &(ei->vfs_inode);
+- u64 i_blocks = inode->i_blocks;
++ u64 i_blocks = READ_ONCE(inode->i_blocks);
+ struct super_block *sb = inode->i_sb;
+
+ if (i_blocks <= ~0U) {
--- /dev/null
+From 25efb2ffdf991177e740b2f63e92b4ec7d310a92 Mon Sep 17 00:00:00 2001
+From: Simon Gander <simon@tuxera.com>
+Date: Fri, 10 Apr 2020 14:32:16 -0700
+Subject: hfsplus: fix crash and filesystem corruption when deleting files
+
+From: Simon Gander <simon@tuxera.com>
+
+commit 25efb2ffdf991177e740b2f63e92b4ec7d310a92 upstream.
+
+When removing files containing extended attributes, the hfsplus driver may
+remove the wrong entries from the attributes b-tree, causing major
+filesystem damage and in some cases even kernel crashes.
+
+To remove a file, all its extended attributes have to be removed as well.
+The driver does this by looking up all keys in the attributes b-tree with
+the cnid of the file. Each of these entries then gets deleted using the
+key used for searching, which doesn't contain the attribute's name when it
+should. Since the key doesn't contain the name, the deletion routine will
+not find the correct entry and instead remove the one in front of it. If
+parent nodes have to be modified, these become corrupt as well. This
+causes invalid links and unsorted entries that not even macOS's fsck_hfs
+is able to fix.
+
+To fix this, modify the search key before an entry is deleted from the
+attributes b-tree by copying the found entry's key into the search key,
+therefore ensuring that the correct entry gets removed from the tree.
+
+Signed-off-by: Simon Gander <simon@tuxera.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Reviewed-by: Anton Altaparmakov <anton@tuxera.com>
+Cc: <stable@vger.kernel.org>
+Link: http://lkml.kernel.org/r/20200327155541.1521-1-simon@tuxera.com
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/hfsplus/attributes.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/hfsplus/attributes.c
++++ b/fs/hfsplus/attributes.c
+@@ -291,6 +291,10 @@ static int __hfsplus_delete_attr(struct
+ return -ENOENT;
+ }
+
++ /* Avoid btree corruption */
++ hfs_bnode_read(fd->bnode, fd->search_key,
++ fd->keyoffset, fd->keylength);
++
+ err = hfs_brec_remove(fd);
+ if (err)
+ return err;
--- /dev/null
+From ebc68cedec4aead47d8d11623d013cca9bf8e825 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 1 Apr 2020 13:23:06 -0700
+Subject: Input: i8042 - add Acer Aspire 5738z to nomux list
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit ebc68cedec4aead47d8d11623d013cca9bf8e825 upstream.
+
+The Acer Aspire 5738z has a button to disable (and re-enable) the
+touchpad next to the touchpad.
+
+When this button is pressed a LED underneath indicates that the touchpad
+is disabled (and an event is send to userspace and GNOME shows its
+touchpad enabled / disable OSD thingie).
+
+So far so good, but after re-enabling the touchpad it no longer works.
+
+The laptop does not have an external ps2 port, so mux mode is not needed
+and disabling mux mode fixes the touchpad no longer working after toggling
+it off and back on again, so lets add this laptop model to the nomux list.
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20200331123947.318908-1-hdegoede@redhat.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/serio/i8042-x86ia64io.h | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/input/serio/i8042-x86ia64io.h
++++ b/drivers/input/serio/i8042-x86ia64io.h
+@@ -534,6 +534,17 @@ static const struct dmi_system_id __init
+ DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo LaVie Z"),
+ },
+ },
++ {
++ /*
++ * Acer Aspire 5738z
++ * Touchpad stops working in mux mode when dis- + re-enabled
++ * with the touchpad enable/disable toggle hotkey
++ */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5738"),
++ },
++ },
+ { }
+ };
+
--- /dev/null
+From d7d27cfc5cf0766a26a8f56868c5ad5434735126 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Fri, 10 Apr 2020 14:33:43 -0700
+Subject: kmod: make request_module() return an error when autoloading is disabled
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit d7d27cfc5cf0766a26a8f56868c5ad5434735126 upstream.
+
+Patch series "module autoloading fixes and cleanups", v5.
+
+This series fixes a bug where request_module() was reporting success to
+kernel code when module autoloading had been completely disabled via
+'echo > /proc/sys/kernel/modprobe'.
+
+It also addresses the issues raised on the original thread
+(https://lkml.kernel.org/lkml/20200310223731.126894-1-ebiggers@kernel.org/T/#u)
+bydocumenting the modprobe sysctl, adding a self-test for the empty path
+case, and downgrading a user-reachable WARN_ONCE().
+
+This patch (of 4):
+
+It's long been possible to disable kernel module autoloading completely
+(while still allowing manual module insertion) by setting
+/proc/sys/kernel/modprobe to the empty string.
+
+This can be preferable to setting it to a nonexistent file since it
+avoids the overhead of an attempted execve(), avoids potential
+deadlocks, and avoids the call to security_kernel_module_request() and
+thus on SELinux-based systems eliminates the need to write SELinux rules
+to dontaudit module_request.
+
+However, when module autoloading is disabled in this way,
+request_module() returns 0. This is broken because callers expect 0 to
+mean that the module was successfully loaded.
+
+Apparently this was never noticed because this method of disabling
+module autoloading isn't used much, and also most callers don't use the
+return value of request_module() since it's always necessary to check
+whether the module registered its functionality or not anyway.
+
+But improperly returning 0 can indeed confuse a few callers, for example
+get_fs_type() in fs/filesystems.c where it causes a WARNING to be hit:
+
+ if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
+ fs = __get_fs_type(name, len);
+ WARN_ONCE(!fs, "request_module fs-%.*s succeeded, but still no fs?\n", len, name);
+ }
+
+This is easily reproduced with:
+
+ echo > /proc/sys/kernel/modprobe
+ mount -t NONEXISTENT none /
+
+It causes:
+
+ request_module fs-NONEXISTENT succeeded, but still no fs?
+ WARNING: CPU: 1 PID: 1106 at fs/filesystems.c:275 get_fs_type+0xd6/0xf0
+ [...]
+
+This should actually use pr_warn_once() rather than WARN_ONCE(), since
+it's also user-reachable if userspace immediately unloads the module.
+Regardless, request_module() should correctly return an error when it
+fails. So let's make it return -ENOENT, which matches the error when
+the modprobe binary doesn't exist.
+
+I've also sent patches to document and test this case.
+
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Jessica Yu <jeyu@kernel.org>
+Acked-by: Luis Chamberlain <mcgrof@kernel.org>
+Cc: Alexei Starovoitov <ast@kernel.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Jeff Vander Stoep <jeffv@google.com>
+Cc: Ben Hutchings <benh@debian.org>
+Cc: Josh Triplett <josh@joshtriplett.org>
+Cc: <stable@vger.kernel.org>
+Link: http://lkml.kernel.org/r/20200310223731.126894-1-ebiggers@kernel.org
+Link: http://lkml.kernel.org/r/20200312202552.241885-1-ebiggers@kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/kmod.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/kernel/kmod.c
++++ b/kernel/kmod.c
+@@ -119,7 +119,7 @@ out:
+ * invoke it.
+ *
+ * If module auto-loading support is disabled then this function
+- * becomes a no-operation.
++ * simply returns -ENOENT.
+ */
+ int __request_module(bool wait, const char *fmt, ...)
+ {
+@@ -140,7 +140,7 @@ int __request_module(bool wait, const ch
+ WARN_ON_ONCE(wait && current_is_async());
+
+ if (!modprobe_path[0])
+- return 0;
++ return -ENOENT;
+
+ va_start(args, fmt);
+ ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
--- /dev/null
+From 8305f72f952cff21ce8109dc1ea4b321c8efc5af Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Wed, 27 Mar 2019 17:02:54 +0800
+Subject: libata: Return correct status in sata_pmp_eh_recover_pm() when ATA_DFLAG_DETACH is set
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit 8305f72f952cff21ce8109dc1ea4b321c8efc5af upstream.
+
+During system resume from suspend, this can be observed on ASM1062 PMP
+controller:
+
+ata10.01: SATA link down (SStatus 0 SControl 330)
+ata10.02: hard resetting link
+ata10.02: SATA link down (SStatus 0 SControl 330)
+ata10.00: configured for UDMA/133
+Kernel panic - not syncing: stack-protector: Kernel
+ in: sata_pmp_eh_recover+0xa2b/0xa40
+
+CPU: 2 PID: 230 Comm: scsi_eh_9 Tainted: P OE
+#49-Ubuntu
+Hardware name: System manufacturer System Product
+ 1001 12/10/2017
+Call Trace:
+dump_stack+0x63/0x8b
+panic+0xe4/0x244
+? sata_pmp_eh_recover+0xa2b/0xa40
+__stack_chk_fail+0x19/0x20
+sata_pmp_eh_recover+0xa2b/0xa40
+? ahci_do_softreset+0x260/0x260 [libahci]
+? ahci_do_hardreset+0x140/0x140 [libahci]
+? ata_phys_link_offline+0x60/0x60
+? ahci_stop_engine+0xc0/0xc0 [libahci]
+sata_pmp_error_handler+0x22/0x30
+ahci_error_handler+0x45/0x80 [libahci]
+ata_scsi_port_error_handler+0x29b/0x770
+? ata_scsi_cmd_error_handler+0x101/0x140
+ata_scsi_error+0x95/0xd0
+? scsi_try_target_reset+0x90/0x90
+scsi_error_handler+0xd0/0x5b0
+kthread+0x121/0x140
+? scsi_eh_get_sense+0x200/0x200
+? kthread_create_worker_on_cpu+0x70/0x70
+ret_from_fork+0x22/0x40
+Kernel Offset: 0xcc00000 from 0xffffffff81000000
+(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
+
+Since sata_pmp_eh_recover_pmp() doens't set rc when ATA_DFLAG_DETACH is
+set, sata_pmp_eh_recover() continues to run. During retry it triggers
+the stack protector.
+
+Set correct rc in sata_pmp_eh_recover_pmp() to let sata_pmp_eh_recover()
+jump to pmp_fail directly.
+
+BugLink: https://bugs.launchpad.net/bugs/1821434
+Cc: stable@vger.kernel.org
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-pmp.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/ata/libata-pmp.c
++++ b/drivers/ata/libata-pmp.c
+@@ -764,6 +764,7 @@ static int sata_pmp_eh_recover_pmp(struc
+
+ if (dev->flags & ATA_DFLAG_DETACH) {
+ detach = 1;
++ rc = -ENODEV;
+ goto fail;
+ }
+
--- /dev/null
+From 783fda856e1034dee90a873f7654c418212d12d7 Mon Sep 17 00:00:00 2001
+From: Changwei Ge <chge@linux.alibaba.com>
+Date: Fri, 10 Apr 2020 14:32:38 -0700
+Subject: ocfs2: no need try to truncate file beyond i_size
+
+From: Changwei Ge <chge@linux.alibaba.com>
+
+commit 783fda856e1034dee90a873f7654c418212d12d7 upstream.
+
+Linux fallocate(2) with FALLOC_FL_PUNCH_HOLE mode set, its offset can
+exceed the inode size. Ocfs2 now doesn't allow that offset beyond inode
+size. This restriction is not necessary and violates fallocate(2)
+semantics.
+
+If fallocate(2) offset is beyond inode size, just return success and do
+nothing further.
+
+Otherwise, ocfs2 will crash the kernel.
+
+ kernel BUG at fs/ocfs2//alloc.c:7264!
+ ocfs2_truncate_inline+0x20f/0x360 [ocfs2]
+ ocfs2_remove_inode_range+0x23c/0xcb0 [ocfs2]
+ __ocfs2_change_file_space+0x4a5/0x650 [ocfs2]
+ ocfs2_fallocate+0x83/0xa0 [ocfs2]
+ vfs_fallocate+0x148/0x230
+ SyS_fallocate+0x48/0x80
+ do_syscall_64+0x79/0x170
+
+Signed-off-by: Changwei Ge <chge@linux.alibaba.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Gang He <ghe@suse.com>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: <stable@vger.kernel.org>
+Link: http://lkml.kernel.org/r/20200407082754.17565-1-chge@linux.alibaba.com
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ocfs2/alloc.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/ocfs2/alloc.c
++++ b/fs/ocfs2/alloc.c
+@@ -7246,6 +7246,10 @@ int ocfs2_truncate_inline(struct inode *
+ struct ocfs2_dinode *di = (struct ocfs2_dinode *)di_bh->b_data;
+ struct ocfs2_inline_data *idata = &di->id2.i_data;
+
++ /* No need to punch hole beyond i_size. */
++ if (start >= i_size_read(inode))
++ return 0;
++
+ if (end > i_size_read(inode))
+ end = i_size_read(inode);
+
--- /dev/null
+From c50156526a2f7176b50134e3e5fb108ba09791b2 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <natechancellor@gmail.com>
+Date: Wed, 31 Oct 2018 17:55:02 -0700
+Subject: rtc: omap: Use define directive for PIN_CONFIG_ACTIVE_HIGH
+
+From: Nathan Chancellor <natechancellor@gmail.com>
+
+commit c50156526a2f7176b50134e3e5fb108ba09791b2 upstream.
+
+Clang warns when one enumerated type is implicitly converted to another:
+
+drivers/rtc/rtc-omap.c:574:21: warning: implicit conversion from
+enumeration type 'enum rtc_pin_config_param' to different enumeration
+type 'enum pin_config_param' [-Wenum-conversion]
+ {"ti,active-high", PIN_CONFIG_ACTIVE_HIGH, 0},
+ ~ ^~~~~~~~~~~~~~~~~~~~~~
+drivers/rtc/rtc-omap.c:579:12: warning: implicit conversion from
+enumeration type 'enum rtc_pin_config_param' to different enumeration
+type 'enum pin_config_param' [-Wenum-conversion]
+ PCONFDUMP(PIN_CONFIG_ACTIVE_HIGH, "input active high", NULL, false),
+ ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from
+macro 'PCONFDUMP'
+ .param = a, .display = b, .format = c, .has_arg = d \
+ ^
+2 warnings generated.
+
+It is expected that pinctrl drivers can extend pin_config_param because
+of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
+isn't an issue. Most drivers that take advantage of this define the
+PIN_CONFIG variables as constants, rather than enumerated values. Do the
+same thing here so that Clang no longer warns.
+
+Link: https://github.com/ClangBuiltLinux/linux/issues/144
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/rtc/rtc-omap.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/rtc/rtc-omap.c
++++ b/drivers/rtc/rtc-omap.c
+@@ -559,9 +559,7 @@ static const struct pinctrl_ops rtc_pinc
+ .dt_free_map = pinconf_generic_dt_free_map,
+ };
+
+-enum rtc_pin_config_param {
+- PIN_CONFIG_ACTIVE_HIGH = PIN_CONFIG_END + 1,
+-};
++#define PIN_CONFIG_ACTIVE_HIGH (PIN_CONFIG_END + 1)
+
+ static const struct pinconf_generic_params rtc_params[] = {
+ {"ti,active-high", PIN_CONFIG_ACTIVE_HIGH, 0},
--- /dev/null
+From 6c7c851f1b666a8a455678a0b480b9162de86052 Mon Sep 17 00:00:00 2001
+From: Michael Mueller <mimu@linux.ibm.com>
+Date: Tue, 3 Mar 2020 16:42:01 +0100
+Subject: s390/diag: fix display of diagnose call statistics
+
+From: Michael Mueller <mimu@linux.ibm.com>
+
+commit 6c7c851f1b666a8a455678a0b480b9162de86052 upstream.
+
+Show the full diag statistic table and not just parts of it.
+
+The issue surfaced in a KVM guest with a number of vcpus
+defined smaller than NR_DIAG_STAT.
+
+Fixes: 1ec2772e0c3c ("s390/diag: add a statistic for diagnose calls")
+Cc: stable@vger.kernel.org
+Signed-off-by: Michael Mueller <mimu@linux.ibm.com>
+Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/diag.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/s390/kernel/diag.c
++++ b/arch/s390/kernel/diag.c
+@@ -76,7 +76,7 @@ static int show_diag_stat(struct seq_fil
+
+ static void *show_diag_stat_start(struct seq_file *m, loff_t *pos)
+ {
+- return *pos <= nr_cpu_ids ? (void *)((unsigned long) *pos + 1) : NULL;
++ return *pos <= NR_DIAG_STAT ? (void *)((unsigned long) *pos + 1) : NULL;
+ }
+
+ static void *show_diag_stat_next(struct seq_file *m, void *v, loff_t *pos)
--- /dev/null
+From 819732be9fea728623e1ed84eba28def7384ad1f Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.ibm.com>
+Date: Thu, 12 Mar 2020 18:44:56 +0100
+Subject: scsi: zfcp: fix missing erp_lock in port recovery trigger for point-to-point
+
+From: Steffen Maier <maier@linux.ibm.com>
+
+commit 819732be9fea728623e1ed84eba28def7384ad1f upstream.
+
+v2.6.27 commit cc8c282963bd ("[SCSI] zfcp: Automatically attach remote
+ports") introduced zfcp automatic port scan.
+
+Before that, the user had to use the sysfs attribute "port_add" of an FCP
+device (adapter) to add and open remote (target) ports, even for the remote
+peer port in point-to-point topology. That code path did a proper port open
+recovery trigger taking the erp_lock.
+
+Since above commit, a new helper function zfcp_erp_open_ptp_port()
+performed an UNlocked port open recovery trigger. This can race with other
+parallel recovery triggers. In zfcp_erp_action_enqueue() this could corrupt
+e.g. adapter->erp_total_count or adapter->erp_ready_head.
+
+As already found for fabric topology in v4.17 commit fa89adba1941 ("scsi:
+zfcp: fix infinite iteration on ERP ready list"), there was an endless loop
+during tracing of rport (un)block. A subsequent v4.18 commit 9e156c54ace3
+("scsi: zfcp: assert that the ERP lock is held when tracing a recovery
+trigger") introduced a lockdep assertion for that case.
+
+As a side effect, that lockdep assertion now uncovered the unlocked code
+path for PtP. It is from within an adapter ERP action:
+
+zfcp_erp_strategy[1479] intentionally DROPs erp lock around
+ zfcp_erp_strategy_do_action()
+zfcp_erp_strategy_do_action[1441] NO erp lock
+zfcp_erp_adapter_strategy[876] NO erp lock
+zfcp_erp_adapter_strategy_open[855] NO erp lock
+zfcp_erp_adapter_strategy_open_fsf[806]NO erp lock
+zfcp_erp_adapter_strat_fsf_xconf[772] erp lock only around
+ zfcp_erp_action_to_running(),
+ BUT *_not_* around
+ zfcp_erp_enqueue_ptp_port()
+zfcp_erp_enqueue_ptp_port[728] BUG: *_not_* taking erp lock
+_zfcp_erp_port_reopen[432] assumes to be called with erp lock
+zfcp_erp_action_enqueue[314] assumes to be called with erp lock
+zfcp_dbf_rec_trig[288] _checks_ to be called with erp lock:
+ lockdep_assert_held(&adapter->erp_lock);
+
+It causes the following lockdep warning:
+
+WARNING: CPU: 2 PID: 775 at drivers/s390/scsi/zfcp_dbf.c:288
+ zfcp_dbf_rec_trig+0x16a/0x188
+no locks held by zfcperp0.0.17c0/775.
+
+Fix this by using the proper locked recovery trigger helper function.
+
+Link: https://lore.kernel.org/r/20200312174505.51294-2-maier@linux.ibm.com
+Fixes: cc8c282963bd ("[SCSI] zfcp: Automatically attach remote ports")
+Cc: <stable@vger.kernel.org> #v2.6.27+
+Reviewed-by: Jens Remus <jremus@linux.ibm.com>
+Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
+Signed-off-by: Steffen Maier <maier@linux.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_erp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/s390/scsi/zfcp_erp.c
++++ b/drivers/s390/scsi/zfcp_erp.c
+@@ -747,7 +747,7 @@ static void zfcp_erp_enqueue_ptp_port(st
+ adapter->peer_d_id);
+ if (IS_ERR(port)) /* error or port already attached */
+ return;
+- _zfcp_erp_port_reopen(port, 0, "ereptp1");
++ zfcp_erp_port_reopen(port, 0, "ereptp1");
+ }
+
+ static int zfcp_erp_adapter_strat_fsf_xconf(struct zfcp_erp_action *erp_action)
x86-speculation-remove-redundant-arch_smt_update-invocation.patch
tools-gpio-fix-out-of-tree-build-regression.patch
mm-use-fixed-constant-in-page_frag_alloc-instead-of-size-1.patch
+dm-verity-fec-fix-memory-leak-in-verity_fec_dtr.patch
+scsi-zfcp-fix-missing-erp_lock-in-port-recovery-trigger-for-point-to-point.patch
+arm64-armv8_deprecated-fix-undef_hook-mask-for-thumb-setend.patch
+rtc-omap-use-define-directive-for-pin_config_active_high.patch
+ext4-fix-a-data-race-at-inode-i_blocks.patch
+ocfs2-no-need-try-to-truncate-file-beyond-i_size.patch
+s390-diag-fix-display-of-diagnose-call-statistics.patch
+input-i8042-add-acer-aspire-5738z-to-nomux-list.patch
+kmod-make-request_module-return-an-error-when-autoloading-is-disabled.patch
+cpufreq-powernv-fix-use-after-free.patch
+hfsplus-fix-crash-and-filesystem-corruption-when-deleting-files.patch
+libata-return-correct-status-in-sata_pmp_eh_recover_pm-when-ata_dflag_detach-is-set.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
