From: Greg Kroah-Hartman Date: Thu, 30 Apr 2020 15:21:48 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v5.4.37~28 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=3b7b70977104e3b943feb778b90fb953de5affa5;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: mm-shmem-disable-interrupt-when-acquiring-info-lock-in-userfaultfd_copy-path.patch xfs-clear-pf_memalloc-before-exiting-xfsaild-thread.patch --- diff --git a/queue-4.19/mm-shmem-disable-interrupt-when-acquiring-info-lock-in-userfaultfd_copy-path.patch b/queue-4.19/mm-shmem-disable-interrupt-when-acquiring-info-lock-in-userfaultfd_copy-path.patch new file mode 100644 index 00000000000..8ead33232a7 --- /dev/null +++ b/queue-4.19/mm-shmem-disable-interrupt-when-acquiring-info-lock-in-userfaultfd_copy-path.patch @@ -0,0 +1,79 @@ +From 94b7cc01da5a3cc4f3da5e0ff492ef008bb555d6 Mon Sep 17 00:00:00 2001 +From: Yang Shi +Date: Mon, 20 Apr 2020 18:14:17 -0700 +Subject: mm: shmem: disable interrupt when acquiring info->lock in userfaultfd_copy path + +From: Yang Shi + +commit 94b7cc01da5a3cc4f3da5e0ff492ef008bb555d6 upstream. + +Syzbot reported the below lockdep splat: + + WARNING: possible irq lock inversion dependency detected + 5.6.0-rc7-syzkaller #0 Not tainted + -------------------------------------------------------- + syz-executor.0/10317 just changed the state of lock: + ffff888021d16568 (&(&info->lock)->rlock){+.+.}, at: spin_lock include/linux/spinlock.h:338 [inline] + ffff888021d16568 (&(&info->lock)->rlock){+.+.}, at: shmem_mfill_atomic_pte+0x1012/0x21c0 mm/shmem.c:2407 + but this lock was taken by another, SOFTIRQ-safe lock in the past: + (&(&xa->xa_lock)->rlock#5){..-.} + + and interrupts could create inverse lock ordering between them. + + other info that might help us debug this: + Possible interrupt unsafe locking scenario: + + CPU0 CPU1 + ---- ---- + lock(&(&info->lock)->rlock); + local_irq_disable(); + lock(&(&xa->xa_lock)->rlock#5); + lock(&(&info->lock)->rlock); + + lock(&(&xa->xa_lock)->rlock#5); + + *** DEADLOCK *** + +The full report is quite lengthy, please see: + + https://lore.kernel.org/linux-mm/alpine.LSU.2.11.2004152007370.13597@eggly.anvils/T/#m813b412c5f78e25ca8c6c7734886ed4de43f241d + +It is because CPU 0 held info->lock with IRQ enabled in userfaultfd_copy +path, then CPU 1 is splitting a THP which held xa_lock and info->lock in +IRQ disabled context at the same time. If softirq comes in to acquire +xa_lock, the deadlock would be triggered. + +The fix is to acquire/release info->lock with *_irq version instead of +plain spin_{lock,unlock} to make it softirq safe. + +Fixes: 4c27fe4c4c84 ("userfaultfd: shmem: add shmem_mcopy_atomic_pte for userfaultfd support") +Reported-by: syzbot+e27980339d305f2dbfd9@syzkaller.appspotmail.com +Signed-off-by: Yang Shi +Signed-off-by: Andrew Morton +Tested-by: syzbot+e27980339d305f2dbfd9@syzkaller.appspotmail.com +Acked-by: Hugh Dickins +Cc: Andrea Arcangeli +Link: http://lkml.kernel.org/r/1587061357-122619-1-git-send-email-yang.shi@linux.alibaba.com +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/shmem.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/mm/shmem.c ++++ b/mm/shmem.c +@@ -2350,11 +2350,11 @@ static int shmem_mfill_atomic_pte(struct + + lru_cache_add_anon(page); + +- spin_lock(&info->lock); ++ spin_lock_irq(&info->lock); + info->alloced++; + inode->i_blocks += BLOCKS_PER_PAGE; + shmem_recalc_inode(inode); +- spin_unlock(&info->lock); ++ spin_unlock_irq(&info->lock); + + inc_mm_counter(dst_mm, mm_counter_file(page)); + page_add_file_rmap(page, false); diff --git a/queue-4.19/series b/queue-4.19/series index c4333f34e3b..135686aabef 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -23,3 +23,5 @@ cpumap-avoid-warning-when-config_debug_per_cpu_maps-is-enabled.patch net-mlx5-fix-failing-fw-tracer-allocation-on-s390.patch perf-core-fix-parent-pid-tid-in-task-exit-events.patch bpf-x86_32-fix-incorrect-encoding-in-bpf_ldx-zero-extension.patch +mm-shmem-disable-interrupt-when-acquiring-info-lock-in-userfaultfd_copy-path.patch +xfs-clear-pf_memalloc-before-exiting-xfsaild-thread.patch diff --git a/queue-4.19/xfs-clear-pf_memalloc-before-exiting-xfsaild-thread.patch b/queue-4.19/xfs-clear-pf_memalloc-before-exiting-xfsaild-thread.patch new file mode 100644 index 00000000000..7f8bbefa088 --- /dev/null +++ b/queue-4.19/xfs-clear-pf_memalloc-before-exiting-xfsaild-thread.patch @@ -0,0 +1,98 @@ +From 10a98cb16d80be3595fdb165fad898bb28b8b6d2 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 10 Mar 2020 08:57:27 -0700 +Subject: xfs: clear PF_MEMALLOC before exiting xfsaild thread + +From: Eric Biggers + +commit 10a98cb16d80be3595fdb165fad898bb28b8b6d2 upstream. + +Leaving PF_MEMALLOC set when exiting a kthread causes it to remain set +during do_exit(). That can confuse things. In particular, if BSD +process accounting is enabled, then do_exit() writes data to an +accounting file. If that file has FS_SYNC_FL set, then this write +occurs synchronously and can misbehave if PF_MEMALLOC is set. + +For example, if the accounting file is located on an XFS filesystem, +then a WARN_ON_ONCE() in iomap_do_writepage() is triggered and the data +doesn't get written when it should. Or if the accounting file is +located on an ext4 filesystem without a journal, then a WARN_ON_ONCE() +in ext4_write_inode() is triggered and the inode doesn't get written. + +Fix this in xfsaild() by using the helper functions to save and restore +PF_MEMALLOC. + +This can be reproduced as follows in the kvm-xfstests test appliance +modified to add the 'acct' Debian package, and with kvm-xfstests's +recommended kconfig modified to add CONFIG_BSD_PROCESS_ACCT=y: + + mkfs.xfs -f /dev/vdb + mount /vdb + touch /vdb/file + chattr +S /vdb/file + accton /vdb/file + mkfs.xfs -f /dev/vdc + mount /vdc + umount /vdc + +It causes: + WARNING: CPU: 1 PID: 336 at fs/iomap/buffered-io.c:1534 + CPU: 1 PID: 336 Comm: xfsaild/vdc Not tainted 5.6.0-rc5 #3 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20191223_100556-anatol 04/01/2014 + RIP: 0010:iomap_do_writepage+0x16b/0x1f0 fs/iomap/buffered-io.c:1534 + [...] + Call Trace: + write_cache_pages+0x189/0x4d0 mm/page-writeback.c:2238 + iomap_writepages+0x1c/0x33 fs/iomap/buffered-io.c:1642 + xfs_vm_writepages+0x65/0x90 fs/xfs/xfs_aops.c:578 + do_writepages+0x41/0xe0 mm/page-writeback.c:2344 + __filemap_fdatawrite_range+0xd2/0x120 mm/filemap.c:421 + file_write_and_wait_range+0x71/0xc0 mm/filemap.c:760 + xfs_file_fsync+0x7a/0x2b0 fs/xfs/xfs_file.c:114 + generic_write_sync include/linux/fs.h:2867 [inline] + xfs_file_buffered_aio_write+0x379/0x3b0 fs/xfs/xfs_file.c:691 + call_write_iter include/linux/fs.h:1901 [inline] + new_sync_write+0x130/0x1d0 fs/read_write.c:483 + __kernel_write+0x54/0xe0 fs/read_write.c:515 + do_acct_process+0x122/0x170 kernel/acct.c:522 + slow_acct_process kernel/acct.c:581 [inline] + acct_process+0x1d4/0x27c kernel/acct.c:607 + do_exit+0x83d/0xbc0 kernel/exit.c:791 + kthread+0xf1/0x140 kernel/kthread.c:257 + ret_from_fork+0x27/0x50 arch/x86/entry/entry_64.S:352 + +This bug was originally reported by syzbot at +https://lore.kernel.org/r/0000000000000e7156059f751d7b@google.com. + +Reported-by: syzbot+1f9dc49e8de2582d90c2@syzkaller.appspotmail.com +Signed-off-by: Eric Biggers +Reviewed-by: Darrick J. Wong +Signed-off-by: Darrick J. Wong +Reviewed-by: Christoph Hellwig +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/xfs_trans_ail.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/fs/xfs/xfs_trans_ail.c ++++ b/fs/xfs/xfs_trans_ail.c +@@ -520,8 +520,9 @@ xfsaild( + { + struct xfs_ail *ailp = data; + long tout = 0; /* milliseconds */ ++ unsigned int noreclaim_flag; + +- current->flags |= PF_MEMALLOC; ++ noreclaim_flag = memalloc_noreclaim_save(); + set_freezable(); + + while (1) { +@@ -592,6 +593,7 @@ xfsaild( + tout = xfsaild_push(ailp); + } + ++ memalloc_noreclaim_restore(noreclaim_flag); + return 0; + } +