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=-11.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 A4DC7C433E2 for ; Tue, 14 Jul 2020 15:47:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 64A7622404 for ; Tue, 14 Jul 2020 15:47:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="mn0Ryrht" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64A7622404 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F29796B000E; Tue, 14 Jul 2020 11:47:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB21A6B0010; Tue, 14 Jul 2020 11:47:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA1366B0022; Tue, 14 Jul 2020 11:47:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0151.hostedemail.com [216.40.44.151]) by kanga.kvack.org (Postfix) with ESMTP id C0CA36B000E for ; Tue, 14 Jul 2020 11:47:08 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7F1E437F1 for ; Tue, 14 Jul 2020 15:47:08 +0000 (UTC) X-FDA: 77037110136.28.slip03_280328226ef2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 489E36C33 for ; Tue, 14 Jul 2020 15:47:08 +0000 (UTC) X-HE-Tag: slip03_280328226ef2 X-Filterd-Recvd-Size: 7641 Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Jul 2020 15:47:07 +0000 (UTC) Received: by mail-ed1-f65.google.com with SMTP id a8so17736884edy.1 for ; Tue, 14 Jul 2020 08:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QXa/a8+v6atJW9I3K/8i8cY/Lmvtpiv+5qg62twrTiI=; b=mn0RyrhtCpG4LO11bnCZa/lH0u4e10/twWy/TsKJcWSQwrFQ5uc6hzPuo8XA/9zijo WXpQOqlkhvbUvdaMnYvaL5yMyMBiI13+6TT7c2XLV0U0dSXQYpZixce2KzXkEc9EMl61 OqZZyQ5PLT6Z1OFgRTGde6rsKiTpakTwwGXYbmnV9rjo/Kjf6jGOKvwGN+YRjLW9lkhC kRnWpIq1+3mRuVGMoYQC1U7VWPy3zx8sqXja+EjvisR61blv1JMOgRN/U/u/wo35VUQo WZNr9i8Jsh/wLAI1XKQxMW1+KlUDFBsmTNNVjEHsl9KYkXD8OHwk3pGLriKFn9pzN7k3 84yw== 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=QXa/a8+v6atJW9I3K/8i8cY/Lmvtpiv+5qg62twrTiI=; b=GDgUXyL+qkDNJ0CoPmRKbRWbvcWsL1Dqf+t62sCRT/H0+wbvB6FD7mVQVM8owoARdr 7jn7hitoo30yARcolUKKT2UaGqRUrkZV4oprMove/kzd2UZbZLukTvNX0Mq6rc0kJLav CjVW5yjG8NQ4IxUOGPnFOBBN6wIvSod57NIbuteFbL/fpRHB/gBENa9D97bqt1nw7vwu xsBcIJnATBf/xeIfXbfR6lu1v/Dvr9JvS9AlXnI8tHy8UAMr32e2WYhpmh6qGkFEN4wy D4AZj2XkHf7XDNXoPGynl/oCWuHbehEX07QW1e9HTHsWyW9mOdP28ITmv+Mlo7vGzvUL fcQA== X-Gm-Message-State: AOAM533nMDG+aENOYsy1T09yLlfiyXZ85FNoNTzQTczM3nRwpp+Lpo+n MVz7B+vMXWeL1ctuNnCsnm9mPwkyG+ItCKf8tsItMA== X-Google-Smtp-Source: ABdhPJy+kyePNsPhuIE7ky0xWpId0cA5UdAi/NGYJUBWmwsXrWoAfYSuKigLeAwba34hq5mKjf42yjcDEybxERrageM= X-Received: by 2002:aa7:dd8e:: with SMTP id g14mr5326572edv.208.1594741626195; Tue, 14 Jul 2020 08:47:06 -0700 (PDT) MIME-Version: 1.0 References: <0000000000000b5f9d059aa2037f@google.com> <20200714033252.8748-1-hdanton@sina.com> <20200714053205.15240-1-hdanton@sina.com> <20200714140859.15156-1-hdanton@sina.com> <20200714141815.GP24642@dhcp22.suse.cz> In-Reply-To: <20200714141815.GP24642@dhcp22.suse.cz> From: Todd Kjos Date: Tue, 14 Jul 2020 08:46:55 -0700 Message-ID: Subject: Re: possible deadlock in shmem_fallocate (4) To: Michal Hocko , Suren Baghdasaryan , Hridya Valsaraju Cc: Hillf Danton , Eric Biggers , syzbot , akpm@linux-foundation.org, =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Christian Brauner , "open list:ANDROID DRIVERS" , Greg Kroah-Hartman , Hugh Dickins , "Joel Fernandes (Google)" , LKML , Linux-MM , Martijn Coenen , syzkaller-bugs , Todd Kjos , Markus Elfring Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 489E36C33 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: +Suren Baghdasaryan +Hridya Valsaraju who support the ashmem driver. On Tue, Jul 14, 2020 at 7:18 AM Michal Hocko wrote: > > On Tue 14-07-20 22:08:59, Hillf Danton wrote: > > > > On Tue, 14 Jul 2020 10:26:29 +0200 Michal Hocko wrote: > > > On Tue 14-07-20 13:32:05, Hillf Danton wrote: > > > > > > > > On Mon, 13 Jul 2020 20:41:11 -0700 Eric Biggers wrote: > > > > > On Tue, Jul 14, 2020 at 11:32:52AM +0800, Hillf Danton wrote: > > > > > > > > > > > > Add FALLOC_FL_NOBLOCK and on the shmem side try to lock inode upon the > > > > > > new flag. And the overall upside is to keep the current gfp either in > > > > > > the khugepaged context or not. > > > > > > > > > > > > --- a/include/uapi/linux/falloc.h > > > > > > +++ b/include/uapi/linux/falloc.h > > > > > > @@ -77,4 +77,6 @@ > > > > > > */ > > > > > > #define FALLOC_FL_UNSHARE_RANGE 0x40 > > > > > > > > > > > > +#define FALLOC_FL_NOBLOCK 0x80 > > > > > > + > > > > > > > > > > You can't add a new UAPI flag to fix a kernel-internal problem like this. > > > > > > > > Sounds fair, see below. > > > > > > > > What the report indicates is a missing PF_MEMALLOC_NOFS and it's > > > > checked on the ashmem side and added as an exception before going > > > > to filesystem. On shmem side, no more than a best effort is paid > > > > on the inteded exception. > > > > > > > > --- a/drivers/staging/android/ashmem.c > > > > +++ b/drivers/staging/android/ashmem.c > > > > @@ -437,6 +437,7 @@ static unsigned long > > > > ashmem_shrink_scan(struct shrinker *shrink, struct shrink_control *sc) > > > > { > > > > unsigned long freed = 0; > > > > + bool nofs; > > > > > > > > /* We might recurse into filesystem code, so bail out if necessary */ > > > > if (!(sc->gfp_mask & __GFP_FS)) > > > > @@ -445,6 +446,11 @@ ashmem_shrink_scan(struct shrinker *shri > > > > if (!mutex_trylock(&ashmem_mutex)) > > > > return -1; > > > > > > > > + /* enter filesystem with caution: nonblock on locking */ > > > > + nofs = current->flags & PF_MEMALLOC_NOFS; > > > > + if (!nofs) > > > > + current->flags |= PF_MEMALLOC_NOFS; > > > > + > > > > while (!list_empty(&ashmem_lru_list)) { > > > > struct ashmem_range *range = > > > > list_first_entry(&ashmem_lru_list, typeof(*range), lru); > > > > > > I do not think this is an appropriate fix. First of all is this a real > > > deadlock or a lockdep false positive? Is it possible that ashmem just > > > > The warning matters and we can do something to quiesce it. > > The underlying issue should be fixed rather than _something_ done to > silence it. > > > > needs to properly annotate its shmem inodes? Or is it possible that > > > the internal backing shmem file is visible to the userspace so the write > > > path would be possible? > > > > > > If this a real problem then the proper fix would be to set internal > > > shmem mapping's gfp_mask to drop __GFP_FS. > > > > Thanks for the tip, see below. > > > > Can you expand a bit on how it helps direct reclaimers like khugepaged > > in the syzbot report wrt deadlock? > > I do not understand your question. > > > TBH I have difficult time following > > up after staring at the chart below for quite a while. > > Yes, lockdep reports are quite hard to follow and they tend to confuse > one hell out of me. But this one says that there is a reclaim dependency > between the shmem inode lock and the reclaim context. > > > Possible unsafe locking scenario: > > > > CPU0 CPU1 > > ---- ---- > > lock(fs_reclaim); > > lock(&sb->s_type->i_mutex_key#15); > > lock(fs_reclaim); > > > > lock(&sb->s_type->i_mutex_key#15); > > Please refrain from proposing fixes until the actual problem is > understood. I suspect that this might be just false positive because the > lockdep cannot tell the backing shmem which is internal to ashmem(?) > with any general shmem. But somebody really familiar with ashmem code > should have a look I believe. > > -- > Michal Hocko > SUSE Labs