On Thu, Jan 26, 2023 at 07:02:14PM -0800, Eric Biggers wrote:
> On Thu, Jan 26, 2023 at 08:23:46PM +0000, Matthew Wilcox (Oracle) wrote:
> > fscrypt_is_bounce_folio() is the equivalent of fscrypt_is_bounce_page()
> > and fscrypt_pagecache_folio() is the equivalent of fscrypt_pagecache_page().
> >
> > Signed-off-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
> > ---
> > include/linux/fscrypt.h | 21 +++++++++++++++++++++
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h
> > index 4f5f8a651213..c2c07d36fb3a 100644
> > --- a/include/linux/fscrypt.h
> > +++ b/include/linux/fscrypt.h
> > @@ -273,6 +273,16 @@ static inline struct page *fscrypt_pagecache_page(struct page *bounce_page)
> > return (struct page *)page_private(bounce_page);
> > }
> >
> > +static inline bool fscrypt_is_bounce_folio(struct folio *folio)
> > +{
> > + return folio->mapping == NULL;
> > +}
> > +
> > +static inline struct folio *fscrypt_pagecache_folio(struct folio *bounce_folio)
> > +{
> > + return bounce_folio->private;
> > +}
>
> ext4_bio_write_folio() is still doing:
>
> bounce_page = fscrypt_encrypt_pagecache_blocks(&folio->page, ...);
>
> Should it be creating a "bounce folio" instead, or is that not in the scope of
> this patchset?
It's out of scope for _this_ patchset. I think it's a patchset that
could come either before or after, and is needed to support large folios
with ext4. The biggest problem with doing that conversion is that
bounce pages are allocated from a mempool which obviously only allocates
order-0 folios. I don't know what to do about that. Have a mempool
for each order of folio that the filesystem supports? Try to allocate
folios without a mempool and then split the folio if allocation fails?
Have a mempool containing PMD-order pages and split them ourselves if
we need to allocate from the mempool?
Nothing's really standing out to me as the perfect answer. There are
probably other alternatives.
