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 44747C433DF for ; Tue, 14 Jul 2020 08:26:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0FC1821835 for ; Tue, 14 Jul 2020 08:26:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0FC1821835 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 5BEC96B0002; Tue, 14 Jul 2020 04:26:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 548A76B0003; Tue, 14 Jul 2020 04:26:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EA8B6B0005; Tue, 14 Jul 2020 04:26:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0082.hostedemail.com [216.40.44.82]) by kanga.kvack.org (Postfix) with ESMTP id 226956B0002 for ; Tue, 14 Jul 2020 04:26:34 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 71756181AC9BF for ; Tue, 14 Jul 2020 08:26:33 +0000 (UTC) X-FDA: 77035999866.19.front94_2a05c6826eef Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 3D23E1AD1B7 for ; Tue, 14 Jul 2020 08:26:33 +0000 (UTC) X-HE-Tag: front94_2a05c6826eef X-Filterd-Recvd-Size: 4879 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Jul 2020 08:26:32 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id a6so20236950wrm.4 for ; Tue, 14 Jul 2020 01:26:32 -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=ns93S8sUjsOmoco+YZg5on386bafVCD/6UpJdLKezho=; b=gVe6tkzEdv/jRS0drdoBA3diMY2Qid9aeM3KLcl/C0QXKBg4QrSggBxXpqm7V0wpes 2XzcR9M7H43oWotqlnzEhzcH0ZBX3PMvUSd1OSAi8V1XU7zChXX/xzrX2RJiA9zvfCu9 0lzZwi+Iq0VHjT7O3ej4hrrftQZeapDseaadxc/KQdws4+bHo0trQMB0IWpECtEvsTLu uj0TF0L7iVZbC9bt6vahzNUOGDVs2K1VEgbHDuamj1XqgUpipP3hjhcIYosp//8n8Rf5 og5bBW5cESx0NpHSet+Ckk7LEbHDsbhccwIcTnXJu0EqahMexxnDKvmhUqRixt+mK2nf veUg== X-Gm-Message-State: AOAM5333JduoIjzeoqSfpPXobGPum+6Y9eBWkmEyh2ninl+YJd53Russ nwD61bSEu+kTmvy5tCfpFE8= X-Google-Smtp-Source: ABdhPJzNwoAmwTV4+wU4QSXAwmcZVDLWLo0xPsnDiu9lYtYjzRw7BLIt7QcH23Kx1jL0n9IEwHuung== X-Received: by 2002:adf:f608:: with SMTP id t8mr3911676wrp.308.1594715191723; Tue, 14 Jul 2020 01:26:31 -0700 (PDT) Received: from localhost (ip-37-188-148-171.eurotel.cz. [37.188.148.171]) by smtp.gmail.com with ESMTPSA id p29sm3326592wmi.43.2020.07.14.01.26.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2020 01:26:30 -0700 (PDT) Date: Tue, 14 Jul 2020 10:26:29 +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: <20200714082629.GF24642@dhcp22.suse.cz> References: <0000000000000b5f9d059aa2037f@google.com> <20200714033252.8748-1-hdanton@sina.com> <20200714053205.15240-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200714053205.15240-1-hdanton@sina.com> X-Rspamd-Queue-Id: 3D23E1AD1B7 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: 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 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. -- Michal Hocko SUSE Labs