On Tue, Mar 14, 2023 at 06:05:51PM -0400, Theodore Ts'o wrote:
> On Fri, Jan 27, 2023 at 04:13:37PM +0000, Matthew Wilcox wrote:
> >
> > 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.
>
> Hmm.... should we have some kind of check in case a large folio is
> passed to these fscrypt functions? (e.g., some kind of BUG_ON, or
> WARN_ON?)
>
> Or do we just rely on people remembering that when we start trying to
> support large folios for ext4, it will probably have to be the easy
> cases first (e.g., no fscrypt, no fsverity, block size == page size)?
>
I think large folio support for fscrypt and fsverity is not that far away. I
already made the following changes in 6.3:
51e4e3153ebc ("fscrypt: support decrypting data from large folios")
5d0f0e57ed90 ("fsverity: support verifying data from large folios")
AFAICT, absent actual testing of course, the only major thing that's still
needed is that fscrypt_encrypt_pagecache_blocks() needs to support large folios.
I'm not sure how it should work, exactly. Matthew gave a couple options.
Another option is to just continue to use bounce *pages*, and keep track of all
the bounce pages for each folio.
We could certainly make fscrypt_encrypt_pagecache_blocks() WARN when given a
large folio for now, if we aren't going to update it properly anytime soon.
By the way, fscrypt_encrypt_pagecache_blocks() is only used by the fs-layer file
contents encryption, not inline encryption. Even without changing it, we could
support large folios on encrypted files when inline encryption is being used.
(A smaller thing, which I think I missed in "fsverity: support verifying data
from large folios", is that fsverity_verify_bio() still uses
bio_first_page_all(bio)->mapping->host to get the bio's inode. Perhaps there
needs to be a page_folio() in there for the ->mapping to be valid?)
- Eric
