Re: [PATCH v6 04/16] iomap: Add flags parameter to iomap_page_create()

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, May 31, 2022 at 11:12:38AM -0700, Stefan Roesch wrote:
> 
> 
> On 5/30/22 11:54 PM, Christoph Hellwig wrote:
> > On Thu, May 26, 2022 at 10:38:28AM -0700, Stefan Roesch wrote:
> >> Add the kiocb flags parameter to the function iomap_page_create().
> >> Depending on the value of the flags parameter it enables different gfp
> >> flags.
> >>
> >> No intended functional changes in this patch.
> >>
> >> Signed-off-by: Stefan Roesch <shr@fb.com>
> >> Reviewed-by: Jan Kara <jack@suse.cz>
> >> ---
> >>  fs/iomap/buffered-io.c | 19 +++++++++++++------
> >>  1 file changed, 13 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> >> index 8ce8720093b9..d6ddc54e190e 100644
> >> --- a/fs/iomap/buffered-io.c
> >> +++ b/fs/iomap/buffered-io.c
> >> @@ -44,16 +44,21 @@ static inline struct iomap_page *to_iomap_page(struct folio *folio)
> >>  static struct bio_set iomap_ioend_bioset;
> >>  
> >>  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;
> >> +
> > 
> > Maybe this would confuse people less if it was:
> > 
> > 	if (flags & IOMAP_NOWAIT)
> > 		gfp = GFP_NOWAIT;
> > 	else
> > 		gfp = GFP_NOFS | __GFP_NOFAIL;
> > 
> 
> I made the above change.

Thanks.  I misread all the gfp handling as:

	gfp_t gfp = GFP_NOFS | __GFP_NOFAIL;

	if (flags & IOMAP_NOWAIT)
		gfp |= GFP_NOWAIT;

Which was why my question did not make sense.  Sorry about that. :(

--D

> 
> > but even as is it is perfectly fine (and I tend to write these kinds of
> > shortcuts as well).
> > 
> > Looks good either way:
> > 
> > Reviewed-by: Christoph Hellwig <hch@lst.de>