--- /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
+@@ -605,7 +605,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 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
+@@ -4485,7 +4485,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
+@@ -7206,6 +7206,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 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)
alsa-hda-initialize-power_state-field-properly.patch
btrfs-incremental-send-fix-invalid-memory-access.patch
ib-ipoib-fix-lockdep-issue-found-on-ipoib_ib_dev_heavy_flush.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
+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
+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
