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=-1.0 required=3.0 tests=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 146AEC2BB1D for ; Fri, 17 Apr 2020 08:00:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CC5AD20644 for ; Fri, 17 Apr 2020 08:00:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC5AD20644 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 91A5D8E0003; Fri, 17 Apr 2020 04:00:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CAF28E0001; Fri, 17 Apr 2020 04:00:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7BAEE8E0003; Fri, 17 Apr 2020 04:00:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0101.hostedemail.com [216.40.44.101]) by kanga.kvack.org (Postfix) with ESMTP id 652878E0001 for ; Fri, 17 Apr 2020 04:00:07 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 18ECC181AEF3E for ; Fri, 17 Apr 2020 08:00:07 +0000 (UTC) X-FDA: 76716598854.28.burst62_3b321bbbb012b X-HE-Tag: burst62_3b321bbbb012b X-Filterd-Recvd-Size: 3774 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Apr 2020 08:00:06 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id b11so1942709wrs.6 for ; Fri, 17 Apr 2020 01:00:06 -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=D9Cm8tiUrg/W1Q7McZQji69rvG+FU5ciQYbgQ4VtKtk=; b=bO6HRZBGgyQVw+vBJm3lkLEhoOPKe/iBglxGt4OPmJC8EOa7QDL2huMndkgk7jZGeN bUl1IohguP2buR+wyN8ng9Y0eNukFSWiF4IF5XWVRqKkGVYXG5OpzrLW6d2SMxvnC4Sy JKsS4TKi7bYGxv+4YhUWhfwtSIZkspARupC6G8Rg2jEGRaEd3Bli7qUgNmAqY4/irxIH mT6pKNeOr6UsT6BCarr5obTVM1SuUQeSgDjoU0Bifipukcz5AtpKpuZL3L0JIhDlcJuh 3sXQP/qzSMSx2MiQ0CyMErV0wBHZ2lY1sOUasBUD84Hj0Lrwjvx1VnANl/QWEFZbsbTh 9r/g== X-Gm-Message-State: AGi0PuZAUTEs+aoGQEefIrYF0xgqwBfYNxWkMtVHvuplbvgEVze/OSda VZ/P1zr1DGfiXUfzPLAE1w4= X-Google-Smtp-Source: APiQypK6QkzwwzEqDKqri8AOStqnCVoQcUWo9VpjG6PFJPc06p38N+Xz35zVVtoaK0x1nCOpRAEbSg== X-Received: by 2002:adf:c109:: with SMTP id r9mr2483924wre.265.1587110405815; Fri, 17 Apr 2020 01:00:05 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id n6sm6585346wmc.28.2020.04.17.01.00.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Apr 2020 01:00:05 -0700 (PDT) Date: Fri, 17 Apr 2020 10:00:03 +0200 From: Michal Hocko To: Christoph Hellwig Cc: "Darrick J. Wong" , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, LKML , Dave Chinner Subject: Re: implicit AOP_FLAG_NOFS for grab_cache_page_write_begin Message-ID: <20200417080003.GH26707@dhcp22.suse.cz> References: <20200415070228.GW4629@dhcp22.suse.cz> <20200417072931.GA20822@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200417072931.GA20822@infradead.org> 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 Fri 17-04-20 00:29:31, Christoph Hellwig wrote: > On Wed, Apr 15, 2020 at 09:02:28AM +0200, Michal Hocko wrote: > > Hi, > > I have just received a bug report about memcg OOM [1]. The underlying > > issue is memcg specific but the stack trace made me look at the write(2) > > patch and I have noticed that iomap_write_begin enforces AOP_FLAG_NOFS > > which means that all the page cache that has to be allocated is > > GFP_NOFS. What is the reason for this? Do all filesystems really need > > the reclaim protection? I was hoping that those filesystems which really > > need NOFS context would be using the scope API > > (memalloc_nofs_{save,restore}. > > This comes from the historic XFS code, and this commit from Dave > in particular: > > commit aea1b9532143218f8599ecedbbd6bfbf812385e1 > Author: Dave Chinner > Date: Tue Jul 20 17:54:12 2010 +1000 > > xfs: use GFP_NOFS for page cache allocation > > Avoid a lockdep warning by preventing page cache allocation from > recursing back into the filesystem during memory reclaim. Thanks for digging this up! The changelog is not really clear whether NOFS is to avoid false possitive lockup warnings or real ones. If the former then we have grown __GFP_NOLOCKDEP flag to workaround the problem if the later then can we use memalloc_nofs_{save,restore} in the xfs specific code please? -- Michal Hocko SUSE Labs