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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 5D9BFC433E0 for ; Tue, 14 Jul 2020 14:20:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1E47C2250F for ; Tue, 14 Jul 2020 14:20:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E47C2250F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 697A96B0002; Tue, 14 Jul 2020 10:20:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 621526B0003; Tue, 14 Jul 2020 10:20:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E7196B0005; Tue, 14 Jul 2020 10:20:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0230.hostedemail.com [216.40.44.230]) by kanga.kvack.org (Postfix) with ESMTP id 318AE6B0002 for ; Tue, 14 Jul 2020 10:20:26 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CCEF7181AC9C6 for ; Tue, 14 Jul 2020 14:20:25 +0000 (UTC) X-FDA: 77036891610.15.alarm72_411644626ef1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 98A2F1801C377 for ; Tue, 14 Jul 2020 14:18:19 +0000 (UTC) X-HE-Tag: alarm72_411644626ef1 X-Filterd-Recvd-Size: 6534 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Jul 2020 14:18:19 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id q5so21947913wru.6 for ; Tue, 14 Jul 2020 07:18:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IPqfDK3T+LSWfa2R0+LOJEnJPN7ZBy864xyViHBmNQo=; b=fnXMXQMKaO93lmhMyRpwaBbP4MwfsYiM1tcx7RQPQNfJT+FSYEHU+5BM1RGMWiEyML 4VQH1lYNe0XEXqHxGOIIDtmkpX1eDWv8GVzFVsOLhUNDp3a0f51Z/dABQa0ctr2dLHVW 4iDX4a8Y0naW59OnElpTaTXbFFblfytlbXA3l3Tx8xlcUyKLDkaQ9DdOF7If53rsiif6 crNeJpXRR11ME9uuzHchiEv7DfAOd9adeNKaxk7nJfKXCBuEM5d2+U/anLikr3B3F0Qi RxK1Q0zDsIVnAAW/yzEBW4F12301x2pKWUDiCi/301G2yOxG46MqlYiQYqdsupTwfiWj 9V2w== X-Gm-Message-State: AOAM531SM6umCQp+TwBKma1ZZEZhxHfUVGUkDOMP/CwrX0yGGSIMw6hx +1OGQgGS2E9SNBpVBdWXXeU= X-Google-Smtp-Source: ABdhPJzSJIFpcy8je8QoaOn+7sTmJWR6ZVWHrZuqwrHxoJvlNfO0Q+GwQhtamDhS1IQi0qFZsgfmtg== X-Received: by 2002:adf:e7c2:: with SMTP id e2mr6250692wrn.179.1594736298161; Tue, 14 Jul 2020 07:18:18 -0700 (PDT) Received: from localhost (ip-37-188-148-171.eurotel.cz. [37.188.148.171]) by smtp.gmail.com with ESMTPSA id 1sm4520678wmf.21.2020.07.14.07.18.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2020 07:18:17 -0700 (PDT) Date: Tue, 14 Jul 2020 16:18:15 +0200 From: Michal Hocko To: Hillf Danton Cc: Eric Biggers , syzbot , akpm@linux-foundation.org, arve@android.com, christian@brauner.io, devel@driverdev.osuosl.org, gregkh@linuxfoundation.org, hughd@google.com, joel@joelfernandes.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, maco@android.com, syzkaller-bugs@googlegroups.com, tkjos@android.com, Markus Elfring Subject: Re: possible deadlock in shmem_fallocate (4) Message-ID: <20200714141815.GP24642@dhcp22.suse.cz> References: <0000000000000b5f9d059aa2037f@google.com> <20200714033252.8748-1-hdanton@sina.com> <20200714053205.15240-1-hdanton@sina.com> <20200714140859.15156-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200714140859.15156-1-hdanton@sina.com> X-Rspamd-Queue-Id: 98A2F1801C377 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 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