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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8415FC433F5 for ; Wed, 1 Jun 2022 01:24:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241193AbiFABYS convert rfc822-to-8bit (ORCPT ); Tue, 31 May 2022 21:24:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231534AbiFABYR (ORCPT ); Tue, 31 May 2022 21:24:17 -0400 X-Greylist: delayed 2991 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Tue, 31 May 2022 18:24:16 PDT Received: from cloud48395.mywhc.ca (cloud48395.mywhc.ca [173.209.37.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A71948CB21; Tue, 31 May 2022 18:24:16 -0700 (PDT) Received: from [45.44.224.220] (port=40386 helo=[192.168.1.179]) by cloud48395.mywhc.ca with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1nwCJa-0005jM-Mx; Tue, 31 May 2022 20:34:22 -0400 Message-ID: <12a76c029e9f3cac279c025776dfb2f59331dca0.camel@olivierlanglois.net> Subject: Re: [PATCH v6 04/16] iomap: Add flags parameter to iomap_page_create() From: Olivier Langlois To: "Darrick J. Wong" , Stefan Roesch Cc: io-uring@vger.kernel.org, kernel-team@fb.com, linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, david@fromorbit.com, jack@suse.cz, hch@infradead.org Date: Tue, 31 May 2022 20:34:20 -0400 In-Reply-To: References: <20220526173840.578265-1-shr@fb.com> <20220526173840.578265-5-shr@fb.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8BIT User-Agent: Evolution 3.44.1 MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud48395.mywhc.ca X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - olivierlanglois.net X-Get-Message-Sender-Via: cloud48395.mywhc.ca: authenticated_id: olivier@olivierlanglois.net X-Authenticated-Sender: cloud48395.mywhc.ca: olivier@olivierlanglois.net X-Source: X-Source-Args: X-Source-Dir: Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Thu, 2022-05-26 at 11:25 -0700, Darrick J. Wong wrote: > On Thu, May 26, 2022 at 10:38:28AM -0700, Stefan Roesch wrote: > > > >  static struct iomap_page * > > -iomap_page_create(struct inode *inode, struct folio *folio) > > +iomap_page_create(struct inode *inode, struct folio *folio, > > unsigned int flags) > >  { > >         struct iomap_page *iop = to_iomap_page(folio); > >         unsigned int nr_blocks = i_blocks_per_folio(inode, folio); > > +       gfp_t gfp = GFP_NOFS | __GFP_NOFAIL; > >   > >         if (iop || nr_blocks <= 1) > >                 return iop; > >   > > +       if (flags & IOMAP_NOWAIT) > > +               gfp = GFP_NOWAIT; > > Hmm.  GFP_NOWAIT means we don't wait for reclaim or IO or filesystem > callbacks, and NOFAIL means we retry indefinitely.  What happens in > the > NOWAIT|NOFAIL case?  Does that imply that the kzalloc loops without > triggering direct reclaim until someone else frees enough memory? > > --D I have a question that is a bit offtopic but since it is concerning GFP flags and this is what is discussed here maybe a participant will kindly give me some hints about this mystery that has burned me for so long... Why does out_of_memory() requires GFP_FS to kill a process? AFAIK, no filesystem-dependent operations are needed to kill a process...