linux-kernel - Re: [PATCH v2 46/46] mm/filemap: Add FGP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Jun 2021 13:15:55 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 46/46] mm/filemap: Add FGP_STABLE

On Wed, Jun 23, 2021 at 01:43:30PM +0200, Christoph Hellwig wrote:
> On Tue, Jun 22, 2021 at 01:15:51PM +0100, Matthew Wilcox (Oracle) wrote:
> > Allow filemap_get_folio() to wait for writeback to complete (if the
> > filesystem wants that behaviour).  This is the folio equivalent of
> > grab_cache_page_write_begin(), which is moved into the folio-compat
> > file as a reminder to migrate all the code using it.  This paves the
> > way for getting rid of AOP_FLAG_NOFS once grab_cache_page_write_begin()
> > is removed.
> 
> We actually should kill FGP_NOFS as well by switching everything over
> to memalloc_nofs_{save, restore} eventually, given how error prone
> all these manual flags settings are.

Well, yes, but it's been four years and we still have over 1100 uses of
GFP_NOFS.  Until someone takes on that Augean Stables, we're going to need
FGP_NOFS.  I added that context to the readahead path in f2c817bed58d,
but of course that doesn't let me remove any uses of GFP_NOFS.

> > diff --git a/mm/folio-compat.c b/mm/folio-compat.c
> > index 78365eaee7d3..206bedd621d0 100644
> > --- a/mm/folio-compat.c
> > +++ b/mm/folio-compat.c
> > @@ -115,6 +115,7 @@ void lru_cache_add(struct page *page)
> >  }
> >  EXPORT_SYMBOL(lru_cache_add);
> >  
> > +noinline
> >  struct page *pagecache_get_page(struct address_space *mapping, pgoff_t index,
> >  		int fgp_flags, gfp_t gfp)
> 
> How did that sneak in here?

Without it, pagecache_get_page() gets inlined by
grab_cache_page_write_begin() which is just too much code.