Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp801708ybz; Wed, 15 Apr 2020 19:26:01 -0700 (PDT) X-Google-Smtp-Source: APiQypITrYuhHPC5UMl6EEGLf1zP926E35FZqQjKMkjY9VqkKI0CT5hYX1vCjLqO/PYaN6Hd5V6l X-Received: by 2002:a17:906:5045:: with SMTP id e5mr7771896ejk.325.1587003961140; Wed, 15 Apr 2020 19:26:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587003961; cv=none; d=google.com; s=arc-20160816; b=y5UStVO1RS3gVe/c64PeSbtbKib1DxWdUeTPR8Upcrr5K+BuGslwbDdhB0N+Fql/uB FG9Y7Q7c1mKNO/3l1KG3GANPq0nD+bqBb/i4y99gmdLeekgDXfGvDt+38URBlA9CFiF/ k0sNaRFuGCbRc10RSjrB+NQbYmqz80rf/acSOoFDXoOoMfbL3xfihKrA8yyxMTfgq+J6 CdT/MG8PCiAicpEMLAAuisQI+AzrhctZEY3Pdd4Eqv9dVrfKlFZ9FiGZlJNET75rO6BY ueljL836cTjdH3quFmZw6/qgOoeZL9ty91TMlKfrtthCzxV4nBEO6txNHVSF6DYT6RFC RFzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=EtplZXDZUCwzEnV8X/3dSx8FEedlAVQg4boarhoDh04=; b=NJqhUlD5Ec6cdOxvkAwuDc96bTdZq7givkxbuypR0CaU3J79cyVJOHtDuufBoxePAz 8yzB0RaERRJkj0HAGrsDqnldcJxIAm4FwlhvnpCDbcORZYr9Q1xTOdJbxlLggzXcC93N /jJjv/SANOHqnVazosreOVi9IRw7kcLnyw5tcxptbvJPyPMH4iQKfWFhO8UDNxBDcpeu ZHYRUZpSwcqfiyuUcFTfUviMZG5SaeO7OBmPAHm0wXp8b/sCTRh6ucfhEysJ/N1rWett Ky0RyIOCxDHN6Q0fjHCCkTqE1P3ZNFLufoUdf6YmJFuiy28NBG9ZdvrjxBuTqwqxup53 nOTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bwe0Vw3V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e17si10499395edj.499.2020.04.15.19.25.37; Wed, 15 Apr 2020 19:26:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bwe0Vw3V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732144AbgDPCXR (ORCPT + 99 others); Wed, 15 Apr 2020 22:23:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1731031AbgDPCXK (ORCPT ); Wed, 15 Apr 2020 22:23:10 -0400 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CCBF8C061A0C for ; Wed, 15 Apr 2020 19:23:08 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id s9so155026eju.1 for ; Wed, 15 Apr 2020 19:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EtplZXDZUCwzEnV8X/3dSx8FEedlAVQg4boarhoDh04=; b=bwe0Vw3VArX62TgjrvU8Fh77fm06SdT16iWG/8aI7WTgEIaYYqaDYYdScO81DO+fpK mH9SC+qkQEiPAdhocSHrwMrUnFKLmPRC8K5fdFsJvw4Ggkrblnkvo+RN5FlOhh/A3OXk MBnsysLVvdsXRQQzJAI+XdM5v18qBdla/g6XWngr0d+F/i3VH3y6yE+50tBSkLCHToTO djhOSiVWuMr5KT346Lf1llmoAw+2Wuzxr7JFBzW/Qhhv376L5Ow0g6SKM8e0EMVssx0G 2sHRlycLi/+hM6tpIFchSavF0r8m5iYGH6oM68OwSNdcgmNLTxGfe+HC2evh2CHRZjlN spbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EtplZXDZUCwzEnV8X/3dSx8FEedlAVQg4boarhoDh04=; b=Iad8fnQ8NatH4XCht5375gCJA1XydTShaER0MV8lZNZ7tp2rM4nMUwJmYxW03N4ChG mCerUbfLBEU69SAXU4VTjPnXGUDyCvi97nzxS22krOlPOjBEPasAuIoroZgGhLOsUlMu MftamZ0avNuG+wrGlvG2RgdAqIWrmzZaLPlvYRuvDFtaPd8FFy4uUB8pePKl2v8Hkvtx 8q6ZmcPm5Z9bs4YdWNkAn1RBzpM2Ve80C9FaMl+/k8HMYr//cBhtjwawhR/BSEDOv6yR dSJE5PthBr/yEI5wWanIZNR2Uh0gB4HuYaqeJesc7l0EiOian9sApQg8hZB9d0cqmFDP STwQ== X-Gm-Message-State: AGi0PuZB+lALv4T5F3aZbG4o0l/1l16ZIMn1Mp/VzP6vacUiGbnGTdgo LqYw7fImXe+7FBmH4OPu1cLTTMueHFzBUY8Z0fQ= X-Received: by 2002:a17:906:69d1:: with SMTP id g17mr7562255ejs.32.1587003787523; Wed, 15 Apr 2020 19:23:07 -0700 (PDT) MIME-Version: 1.0 References: <000000000000571acf05a229cb2f@google.com> In-Reply-To: From: Yang Shi Date: Wed, 15 Apr 2020 19:22:55 -0700 Message-ID: Subject: Re: possible deadlock in shmem_mfill_atomic_pte To: Hugh Dickins Cc: syzbot , Andrew Morton , Linux Kernel Mailing List , Linux MM , syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 15, 2020 at 6:27 PM Hugh Dickins wrote: > > On Mon, 13 Apr 2020, Yang Shi wrote: > > On Tue, Mar 31, 2020 at 10:21 AM syzbot > > wrote: > > > > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit: 527630fb Merge tag 'clk-fixes-for-linus' of git://git.kern.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1214875be00000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=e27980339d305f2dbfd9 > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+e27980339d305f2dbfd9@syzkaller.appspotmail.com > > > > > > 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 *** > > > > This looks possible. shmem_mfill_atomic_pte() acquires info->lock with > > irq enabled. > > > > The below patch should be able to fix it: > > I agree, thank you: please send to akpm with your signoff and > > Reported-by: syzbot+e27980339d305f2dbfd9@syzkaller.appspotmail.com > Fixes: 4c27fe4c4c84 ("userfaultfd: shmem: add shmem_mcopy_atomic_pte for userfaultfd support") > Acked-by: Hugh Dickins > > I bet that 4.11 commit was being worked on before 4.8 reversed the > ordering of info->lock and tree_lock, changing spin_lock(&info->lock)s > to spin_lock_irq*(&info->lock)s - this one is the only hold-out; and > not using userfaultfd, I wouldn't have seen the lockdep report. Thanks, Hugh. I believe this commit could fix the splat. I'm trying to push my test tree to github to let syzkaller test it. I will send the formal patch once I get it tested. It is just slow to push to github, less than 50KB/s... > > > > > diff --git a/mm/shmem.c b/mm/shmem.c > > index d722eb8..762da6a 100644 > > --- a/mm/shmem.c > > +++ b/mm/shmem.c > > @@ -2399,11 +2399,11 @@ static int shmem_mfill_atomic_pte(struct > > mm_struct *dst_mm, > > > > 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);