]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.14-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 15 Apr 2020 11:57:17 +0000 (13:57 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 15 Apr 2020 11:57:17 +0000 (13:57 +0200)
added patches:
arm64-armv8_deprecated-fix-undef_hook-mask-for-thumb-setend.patch
cpufreq-powernv-fix-use-after-free.patch
dm-verity-fec-fix-memory-leak-in-verity_fec_dtr.patch
ext4-fix-a-data-race-at-inode-i_blocks.patch
fs-filesystems.c-downgrade-user-reachable-warn_once-to-pr_warn_once.patch
hfsplus-fix-crash-and-filesystem-corruption-when-deleting-files.patch
input-i8042-add-acer-aspire-5738z-to-nomux-list.patch
kmod-make-request_module-return-an-error-when-autoloading-is-disabled.patch
libata-return-correct-status-in-sata_pmp_eh_recover_pm-when-ata_dflag_detach-is-set.patch
nfs-fix-a-page-leak-in-nfs_destroy_unlinked_subrequests.patch
ocfs2-no-need-try-to-truncate-file-beyond-i_size.patch
perf-tools-support-python-3.8-in-makefile.patch
rtc-omap-use-define-directive-for-pin_config_active_high.patch
s390-diag-fix-display-of-diagnose-call-statistics.patch
scsi-zfcp-fix-missing-erp_lock-in-port-recovery-trigger-for-point-to-point.patch

17 files changed:
queue-4.14/arm64-armv8_deprecated-fix-undef_hook-mask-for-thumb-setend.patch [new file with mode: 0644]
queue-4.14/arm64-dts-allwinner-h6-fix-pmu-compatible.patch [deleted file]
queue-4.14/cpufreq-powernv-fix-use-after-free.patch [new file with mode: 0644]
queue-4.14/dm-verity-fec-fix-memory-leak-in-verity_fec_dtr.patch [new file with mode: 0644]
queue-4.14/ext4-fix-a-data-race-at-inode-i_blocks.patch [new file with mode: 0644]
queue-4.14/fs-filesystems.c-downgrade-user-reachable-warn_once-to-pr_warn_once.patch [new file with mode: 0644]
queue-4.14/hfsplus-fix-crash-and-filesystem-corruption-when-deleting-files.patch [new file with mode: 0644]
queue-4.14/input-i8042-add-acer-aspire-5738z-to-nomux-list.patch [new file with mode: 0644]
queue-4.14/kmod-make-request_module-return-an-error-when-autoloading-is-disabled.patch [new file with mode: 0644]
queue-4.14/libata-return-correct-status-in-sata_pmp_eh_recover_pm-when-ata_dflag_detach-is-set.patch [new file with mode: 0644]
queue-4.14/nfs-fix-a-page-leak-in-nfs_destroy_unlinked_subrequests.patch [new file with mode: 0644]
queue-4.14/ocfs2-no-need-try-to-truncate-file-beyond-i_size.patch [new file with mode: 0644]
queue-4.14/perf-tools-support-python-3.8-in-makefile.patch [new file with mode: 0644]
queue-4.14/rtc-omap-use-define-directive-for-pin_config_active_high.patch [new file with mode: 0644]
queue-4.14/s390-diag-fix-display-of-diagnose-call-statistics.patch [new file with mode: 0644]
queue-4.14/scsi-zfcp-fix-missing-erp_lock-in-port-recovery-trigger-for-point-to-point.patch [new file with mode: 0644]
queue-4.14/series

diff --git a/queue-4.14/arm64-armv8_deprecated-fix-undef_hook-mask-for-thumb-setend.patch b/queue-4.14/arm64-armv8_deprecated-fix-undef_hook-mask-for-thumb-setend.patch
new file mode 100644 (file)
index 0000000..242ce19
--- /dev/null
@@ -0,0 +1,53 @@
+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
+@@ -607,7 +607,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),
diff --git a/queue-4.14/arm64-dts-allwinner-h6-fix-pmu-compatible.patch b/queue-4.14/arm64-dts-allwinner-h6-fix-pmu-compatible.patch
deleted file mode 100644 (file)
index 47e02eb..0000000
+++ /dev/null
@@ -1,35 +0,0 @@
-From 4c7eeb9af3e41ae7d840977119c58f3bbb3f4f59 Mon Sep 17 00:00:00 2001
-From: Maxime Ripard <maxime@cerno.tech>
-Date: Mon, 10 Feb 2020 10:56:00 +0100
-Subject: arm64: dts: allwinner: h6: Fix PMU compatible
-
-From: Maxime Ripard <maxime@cerno.tech>
-
-commit 4c7eeb9af3e41ae7d840977119c58f3bbb3f4f59 upstream.
-
-The commit 7aa9b9eb7d6a ("arm64: dts: allwinner: H6: Add PMU mode")
-introduced support for the PMU found on the Allwinner H6. However, the
-binding only allows for a single compatible, while the patch was adding
-two.
-
-Make sure we follow the binding.
-
-Fixes: 7aa9b9eb7d6a ("arm64: dts: allwinner: H6: Add PMU mode")
-Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-Cc: Guenter Roeck <linux@roeck-us.net>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
-diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
-index 41b58ffa8596..967249e58811 100644
---- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
-+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
-@@ -70,8 +70,7 @@
-       };
-       pmu {
--              compatible = "arm,cortex-a53-pmu",
--                           "arm,armv8-pmuv3";
-+              compatible = "arm,cortex-a53-pmu";
-               interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
-                            <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
-                            <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/queue-4.14/cpufreq-powernv-fix-use-after-free.patch b/queue-4.14/cpufreq-powernv-fix-use-after-free.patch
new file mode 100644 (file)
index 0000000..adb6b99
--- /dev/null
@@ -0,0 +1,46 @@
+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
+@@ -1041,6 +1041,12 @@ free_and_return:
+ 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);
+ }
diff --git a/queue-4.14/dm-verity-fec-fix-memory-leak-in-verity_fec_dtr.patch b/queue-4.14/dm-verity-fec-fix-memory-leak-in-verity_fec_dtr.patch
new file mode 100644 (file)
index 0000000..f71d723
--- /dev/null
@@ -0,0 +1,57 @@
+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
+@@ -552,6 +552,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)
diff --git a/queue-4.14/ext4-fix-a-data-race-at-inode-i_blocks.patch b/queue-4.14/ext4-fix-a-data-race-at-inode-i_blocks.patch
new file mode 100644 (file)
index 0000000..80533cb
--- /dev/null
@@ -0,0 +1,90 @@
+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
+@@ -4981,7 +4981,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) {
diff --git a/queue-4.14/fs-filesystems.c-downgrade-user-reachable-warn_once-to-pr_warn_once.patch b/queue-4.14/fs-filesystems.c-downgrade-user-reachable-warn_once-to-pr_warn_once.patch
new file mode 100644 (file)
index 0000000..706d154
--- /dev/null
@@ -0,0 +1,55 @@
+From 26c5d78c976ca298e59a56f6101a97b618ba3539 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Fri, 10 Apr 2020 14:33:47 -0700
+Subject: fs/filesystems.c: downgrade user-reachable WARN_ONCE() to pr_warn_once()
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 26c5d78c976ca298e59a56f6101a97b618ba3539 upstream.
+
+After request_module(), nothing is stopping the module from being
+unloaded until someone takes a reference to it via try_get_module().
+
+The WARN_ONCE() in get_fs_type() is thus user-reachable, via userspace
+running 'rmmod' concurrently.
+
+Since WARN_ONCE() is for kernel bugs only, not for user-reachable
+situations, downgrade this warning to pr_warn_once().
+
+Keep it printed once only, since the intent of this warning is to detect
+a bug in modprobe at boot time.  Printing the warning more than once
+wouldn't really provide any useful extra information.
+
+Fixes: 41124db869b7 ("fs: warn in case userspace lied about modprobe return")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Reviewed-by: Jessica Yu <jeyu@kernel.org>
+Cc: Alexei Starovoitov <ast@kernel.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Jeff Vander Stoep <jeffv@google.com>
+Cc: Jessica Yu <jeyu@kernel.org>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Luis Chamberlain <mcgrof@kernel.org>
+Cc: NeilBrown <neilb@suse.com>
+Cc: <stable@vger.kernel.org>           [4.13+]
+Link: http://lkml.kernel.org/r/20200312202552.241885-3-ebiggers@kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/filesystems.c |    4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/filesystems.c
++++ b/fs/filesystems.c
+@@ -279,7 +279,9 @@ struct file_system_type *get_fs_type(con
+       fs = __get_fs_type(name, len);
+       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);
++              if (!fs)
++                      pr_warn_once("request_module fs-%.*s succeeded, but still no fs?\n",
++                                   len, name);
+       }
+       if (dot && fs && !(fs->fs_flags & FS_HAS_SUBTYPE)) {
diff --git a/queue-4.14/hfsplus-fix-crash-and-filesystem-corruption-when-deleting-files.patch b/queue-4.14/hfsplus-fix-crash-and-filesystem-corruption-when-deleting-files.patch
new file mode 100644 (file)
index 0000000..822fc53
--- /dev/null
@@ -0,0 +1,52 @@
+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
+@@ -292,6 +292,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;
diff --git a/queue-4.14/input-i8042-add-acer-aspire-5738z-to-nomux-list.patch b/queue-4.14/input-i8042-add-acer-aspire-5738z-to-nomux-list.patch
new file mode 100644 (file)
index 0000000..7448d47
--- /dev/null
@@ -0,0 +1,52 @@
+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"),
++              },
++      },
+       { }
+ };
diff --git a/queue-4.14/kmod-make-request_module-return-an-error-when-autoloading-is-disabled.patch b/queue-4.14/kmod-make-request_module-return-an-error-when-autoloading-is-disabled.patch
new file mode 100644 (file)
index 0000000..9533e05
--- /dev/null
@@ -0,0 +1,108 @@
+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
+@@ -120,7 +120,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, ...)
+ {
+@@ -137,7 +137,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);
diff --git a/queue-4.14/libata-return-correct-status-in-sata_pmp_eh_recover_pm-when-ata_dflag_detach-is-set.patch b/queue-4.14/libata-return-correct-status-in-sata_pmp_eh_recover_pm-when-ata_dflag_detach-is-set.patch
new file mode 100644 (file)
index 0000000..a402cd8
--- /dev/null
@@ -0,0 +1,74 @@
+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;
+       }
diff --git a/queue-4.14/nfs-fix-a-page-leak-in-nfs_destroy_unlinked_subrequests.patch b/queue-4.14/nfs-fix-a-page-leak-in-nfs_destroy_unlinked_subrequests.patch
new file mode 100644 (file)
index 0000000..6fc2658
--- /dev/null
@@ -0,0 +1,31 @@
+From add42de31721fa29ed77a7ce388674d69f9d31a4 Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+Date: Wed, 1 Apr 2020 10:07:16 -0400
+Subject: NFS: Fix a page leak in nfs_destroy_unlinked_subrequests()
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+commit add42de31721fa29ed77a7ce388674d69f9d31a4 upstream.
+
+When we detach a subrequest from the list, we must also release the
+reference it holds to the parent.
+
+Fixes: 5b2b5187fa85 ("NFS: Fix nfs_page_group_destroy() and nfs_lock_and_join_requests() race cases")
+Cc: stable@vger.kernel.org # v4.14+
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/write.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/nfs/write.c
++++ b/fs/nfs/write.c
+@@ -422,6 +422,7 @@ nfs_destroy_unlinked_subrequests(struct
+               }
+               subreq->wb_head = subreq;
++              nfs_release_request(old_head);
+               if (test_and_clear_bit(PG_INODE_REF, &subreq->wb_flags)) {
+                       nfs_release_request(subreq);
diff --git a/queue-4.14/ocfs2-no-need-try-to-truncate-file-beyond-i_size.patch b/queue-4.14/ocfs2-no-need-try-to-truncate-file-beyond-i_size.patch
new file mode 100644 (file)
index 0000000..920cb80
--- /dev/null
@@ -0,0 +1,59 @@
+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
+@@ -7240,6 +7240,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);
diff --git a/queue-4.14/perf-tools-support-python-3.8-in-makefile.patch b/queue-4.14/perf-tools-support-python-3.8-in-makefile.patch
new file mode 100644 (file)
index 0000000..d7be529
--- /dev/null
@@ -0,0 +1,59 @@
+From b9c9ce4e598e012ca7c1813fae2f4d02395807de Mon Sep 17 00:00:00 2001
+From: Sam Lunt <samueljlunt@gmail.com>
+Date: Fri, 31 Jan 2020 12:11:23 -0600
+Subject: perf tools: Support Python 3.8+ in Makefile
+
+From: Sam Lunt <samueljlunt@gmail.com>
+
+commit b9c9ce4e598e012ca7c1813fae2f4d02395807de upstream.
+
+Python 3.8 changed the output of 'python-config --ldflags' to no longer
+include the '-lpythonX.Y' flag (this apparently fixed an issue loading
+modules with a statically linked Python executable).  The libpython
+feature check in linux/build/feature fails if the Python library is not
+included in FEATURE_CHECK_LDFLAGS-libpython variable.
+
+This adds a check in the Makefile to determine if PYTHON_CONFIG accepts
+the '--embed' flag and passes that flag alongside '--ldflags' if so.
+
+tools/perf is the only place the libpython feature check is used.
+
+Signed-off-by: Sam Lunt <samuel.j.lunt@gmail.com>
+Tested-by: He Zhe <zhe.he@windriver.com>
+Link: http://lore.kernel.org/lkml/c56be2e1-8111-9dfe-8298-f7d0f9ab7431@windriver.com
+Acked-by: Jiri Olsa <jolsa@redhat.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: trivial@kernel.org
+Cc: stable@kernel.org
+Link: http://lore.kernel.org/lkml/20200131181123.tmamivhq4b7uqasr@gmail.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/Makefile.config |   11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/Makefile.config
++++ b/tools/perf/Makefile.config
+@@ -179,8 +179,17 @@ strip-libs  = $(filter-out -l%,$(1))
+ PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG))
++# Python 3.8 changed the output of `python-config --ldflags` to not include the
++# '-lpythonX.Y' flag unless '--embed' is also passed. The feature check for
++# libpython fails if that flag is not included in LDFLAGS
++ifeq ($(shell $(PYTHON_CONFIG_SQ) --ldflags --embed 2>&1 1>/dev/null; echo $$?), 0)
++  PYTHON_CONFIG_LDFLAGS := --ldflags --embed
++else
++  PYTHON_CONFIG_LDFLAGS := --ldflags
++endif
++
+ ifdef PYTHON_CONFIG
+-  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
++  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) $(PYTHON_CONFIG_LDFLAGS) 2>/dev/null)
+   PYTHON_EMBED_LDFLAGS := $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
+   PYTHON_EMBED_LIBADD := $(call grep-libs,$(PYTHON_EMBED_LDOPTS)) -lutil
+   PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
diff --git a/queue-4.14/rtc-omap-use-define-directive-for-pin_config_active_high.patch b/queue-4.14/rtc-omap-use-define-directive-for-pin_config_active_high.patch
new file mode 100644 (file)
index 0000000..25ff89f
--- /dev/null
@@ -0,0 +1,55 @@
+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},
diff --git a/queue-4.14/s390-diag-fix-display-of-diagnose-call-statistics.patch b/queue-4.14/s390-diag-fix-display-of-diagnose-call-statistics.patch
new file mode 100644 (file)
index 0000000..28b995d
--- /dev/null
@@ -0,0 +1,36 @@
+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
+@@ -79,7 +79,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)
diff --git a/queue-4.14/scsi-zfcp-fix-missing-erp_lock-in-port-recovery-trigger-for-point-to-point.patch b/queue-4.14/scsi-zfcp-fix-missing-erp_lock-in-port-recovery-trigger-for-point-to-point.patch
new file mode 100644 (file)
index 0000000..fc143c0
--- /dev/null
@@ -0,0 +1,79 @@
+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)
index 79c13fb651dd587d3224d64cf23c463df4221138..7a959da24638b4f6f40db470303f0e8857e8e327 100644 (file)
@@ -69,4 +69,18 @@ powerpc-pseries-drop-pointless-static-qualifier-in-vpa_debugfs_init.patch
 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
-arm64-dts-allwinner-h6-fix-pmu-compatible.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
+nfs-fix-a-page-leak-in-nfs_destroy_unlinked_subrequests.patch
+ext4-fix-a-data-race-at-inode-i_blocks.patch
+fs-filesystems.c-downgrade-user-reachable-warn_once-to-pr_warn_once.patch
+ocfs2-no-need-try-to-truncate-file-beyond-i_size.patch
+perf-tools-support-python-3.8-in-makefile.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