From: Greg Kroah-Hartman Date: Thu, 30 Apr 2020 15:21:35 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v5.4.37~29 X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=fd4d8fb58c3f10fd6168c1f115e92b89a2d8c2fb;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: mm-shmem-disable-interrupt-when-acquiring-info-lock-in-userfaultfd_copy-path.patch --- diff --git a/queue-4.14/mm-shmem-disable-interrupt-when-acquiring-info-lock-in-userfaultfd_copy-path.patch b/queue-4.14/mm-shmem-disable-interrupt-when-acquiring-info-lock-in-userfaultfd_copy-path.patch new file mode 100644 index 00000000000..b29cb5814f2 --- /dev/null +++ b/queue-4.14/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 +@@ -2330,11 +2330,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.14/series b/queue-4.14/series index 90bee56dd2e..fcb40ce69b9 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -94,3 +94,4 @@ i2c-altera-use-proper-variable-to-hold-errno.patch net-cxgb4-check-the-return-from-t4_query_params-properly.patch arm-dts-bcm283x-disable-dsi0-node.patch perf-core-fix-parent-pid-tid-in-task-exit-events.patch +mm-shmem-disable-interrupt-when-acquiring-info-lock-in-userfaultfd_copy-path.patch