From: Eric Biggers <ebiggers@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Theodore Y . Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fscrypt: Change fscrypt_encrypt_pagecache_blocks() to take a folio
Date: Fri, 21 Feb 2025 21:09:38 +0000 [thread overview]
Message-ID: <20250221210938.GB3790599@google.com> (raw)
In-Reply-To: <Z7gQjS34D_Xg_uVo@casper.infradead.org>
On Fri, Feb 21, 2025 at 05:35:09AM +0000, Matthew Wilcox wrote:
> On Thu, Feb 20, 2025 at 09:16:07PM -0800, Eric Biggers wrote:
> > On Fri, Feb 21, 2025 at 05:10:01AM +0000, Matthew Wilcox (Oracle) wrote:
> > > ext4 and ceph already have a folio to pass; f2fs needs to be properly
> > > converted but this will do for now. This removes a reference
> > > to page->index and page->mapping as well as removing a call to
> > > compound_head().
> > >
> > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> >
> > It's still assumed to be a small folio though, right? It still just allocates a
> > "bounce page", not a "bounce folio".
>
> Yup, I haven't figured out how to do large folio support, so any
> filesystem using fscrypt can't support large folios for now. I'm
> working on "separate folio and page" at the moment rather than "enable
> large folios everywhere".
It might be a good idea to make the limitation to small folios clear in the
function's kerneldoc and/or in a WARN_ON_ONCE().
> Maybe someone else will figure out how to
> support large folios in fscrypt and I won't have to ;-)
Decryption is easy and already done, but encryption is harder. We have to
encrypt into bounce pages, since we can't overwrite the plaintext in the page
cache. And when encrypting a large folio, I don't think we can rely on being
able to allocate a large bounce folio of the same size; it may just not be
available at the time. So we'd still need bounce pages, and the filesystem
would have to keep track of potentially multiple bounce pages per folio.
However, this is all specific to the original fs-layer file contents encryption
path. The newer inline crypto one should just work, even without hardware
support since block/blk-crypto-fallback.c would be used. (blk-crypto-fallback
operates at the bio level, handles en/decryption, and manages bounce pages
itself.) It actually might be time to remove the fs-layer file contents
encryption path and just support the inline crypto one.
- Eric
next prev parent reply other threads:[~2025-02-21 21:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-21 5:10 [PATCH] fscrypt: Change fscrypt_encrypt_pagecache_blocks() to take a folio Matthew Wilcox (Oracle)
2025-02-21 5:16 ` Eric Biggers
2025-02-21 5:35 ` Matthew Wilcox
2025-02-21 21:09 ` Eric Biggers [this message]
2025-02-21 22:22 ` Matthew Wilcox
2025-02-21 22:41 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250221210938.GB3790599@google.com \
--to=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.