From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3831BC2BA19 for ; Thu, 16 Apr 2020 02:23:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E085C20737 for ; Thu, 16 Apr 2020 02:23:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bwe0Vw3V" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E085C20737 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 85B238E006E; Wed, 15 Apr 2020 22:23:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 80C4D8E0001; Wed, 15 Apr 2020 22:23:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FBB38E006E; Wed, 15 Apr 2020 22:23:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id 55D828E0001 for ; Wed, 15 Apr 2020 22:23:09 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 17601180AD801 for ; Thu, 16 Apr 2020 02:23:09 +0000 (UTC) X-FDA: 76712120898.13.dime26_72c3b07eeeb35 X-HE-Tag: dime26_72c3b07eeeb35 X-Filterd-Recvd-Size: 6620 Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com [209.85.218.66]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Apr 2020 02:23:08 +0000 (UTC) Received: by mail-ej1-f66.google.com with SMTP id b9so154309ejb.3 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=RJJHbUZhyRsQFRSPHj3rzrr2q4JEXl/kVrLVt0Ste9MmJo7h51idJl3Tb6jYnIo9qs RAFqFZ0ubdQen5PTLKybnmRPERHXdaTRXJx+wJGFfjTQK5Xf5KmgaP10iyhBVDSuuSVW 0gaBMPSj6HLOHf5vt3WeZgFrzqoUm87QGQrnG6Sk3i8HokBdgyJGmBcy4P6k1KonCrWH qAz3W/k2f5Pj2BRIg0ngyKSG3+s1SiySPq44jhzXfiVdC1WX37KxmGqMr+kMO1e9fZxS 7y3SfcP1W1uWGrAy22ZfnrV3drPUQ7NNtPmP2rGEYeMPOpDQfHo+wiQcEzPT8kM22rdj IMDA== X-Gm-Message-State: AGi0PubIfNlUqlg2urKgXlsvAhA6y+m//nTlx+EdQiKanb8ExirhVYQZ Mk8FlBwR/Qok5+csXpxmVtmLCMWIjEVBv3L4Iqw= X-Google-Smtp-Source: APiQypKQLDQm//wlhKhDfnLbV2Q7gFE6oZMcleTwlmpVn5sjjYzf0CIqQb0qZXsfjW++lRO1RPO7rAZrL7b0z/E682s= 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" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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);