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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,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 1AFB5C2BB55 for ; Fri, 17 Apr 2020 08:06:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D4A51214AF for ; Fri, 17 Apr 2020 08:06:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="QEuXKVnz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4A51214AF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6F26A8E0003; Fri, 17 Apr 2020 04:06:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A4008E0001; Fri, 17 Apr 2020 04:06:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B8EF8E0003; Fri, 17 Apr 2020 04:06:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 425258E0001 for ; Fri, 17 Apr 2020 04:06:18 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id F3ABD180ACF9A for ; Fri, 17 Apr 2020 08:06:17 +0000 (UTC) X-FDA: 76716614394.21.crowd56_712da792fd910 X-HE-Tag: crowd56_712da792fd910 X-Filterd-Recvd-Size: 3033 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Apr 2020 08:06:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=GdTc/Zzu7raszzr4RX7T2guEFF3lDB9CYabZTEfgBXY=; b=QEuXKVnz/XP2KY6qvCoCoaxFZL YwfX8YOjMokAprB4nQ8NvkRK6Y7bq+HQj7ySjWENQUmqgjWp0Dyd40wFTB93WA0h1/EkJTY0PlArV 1RnVEggjkzQnKMr6CiIMwXPzvEyacIoHPOZm0owh/M0tBuS8aYB8th13ZpJhGGaTvDJUXLvDKapSN AVegpSoGABDu6ZPjFVK5MKczDpqh7hhQbKXTWXU3Ne73CJspy8uLw2Et0VKGNC68byShygHd5meEG hVUgUPYhWnYBbTJYPHw/n5U1wSTJ7ctlldij8PpHRRBT6w4Dz1CyX/r9eby2Jagy4Ld0jr+GkAsmD oiPBO0cA==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jPM0t-00019y-2j; Fri, 17 Apr 2020 08:06:15 +0000 Date: Fri, 17 Apr 2020 01:06:15 -0700 From: Christoph Hellwig To: Michal Hocko Cc: Christoph Hellwig , "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: <20200417080615.GA26880@infradead.org> References: <20200415070228.GW4629@dhcp22.suse.cz> <20200417072931.GA20822@infradead.org> <20200417080003.GH26707@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200417080003.GH26707@dhcp22.suse.cz> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html 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, Apr 17, 2020 at 10:00:03AM +0200, Michal Hocko wrote: > > 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? As far as I can tell we are never in a file system transaction in XFS when allocating page cache pages. We do, however usually have i_rwsem locked (or back in the day the XFS-specific predecessor). I'm not sure what the current issues are, but maybe Dave remembers. In doubt we should try removing the flag and run heavy stress testing with lockdep enabled and see if it screams.