On Tue, Jul 15, 2025 at 07:37:35AM +0200, Christoph Hellwig wrote: > On Tue, Jul 15, 2025 at 02:18:10AM +0000, Eric Biggers wrote: > > On Fri, Jul 11, 2025 at 10:18:52AM -0700, Bart Van Assche wrote: > > > @@ -124,9 +125,13 @@ static struct bio *bio_submit_split(struct bio *bio, int split_sectors) > > > trace_block_split(split, bio->bi_iter.bi_sector); > > > WARN_ON_ONCE(bio_zone_write_plugging(bio)); > > > submit_bio_noacct(bio); > > > - return split; > > > + > > > + bio = split; > > > } > > > > > > + if (unlikely(!blk_crypto_bio_prep(&bio))) > > > + return NULL; > > > > Is this reached for every bio for every block device? > > No. > > > If not, then this > > patch causes data to sometimes be left unencrypted when the submitter of > > the bio provided an encryption context, which isn't okay. > > I agree, but I think the root problem is the blind assumption that > everything can encrypt. That is a huge mistake and really limits the > block layer. I think we need to fix that first and tell the upper > layers what can encrypt, including using the fallback where we think > it is suitable. I've actually been thinking of going in the other direction: dropping the support for fs-layer file contents encryption from ext4 and f2fs, and instead just relying on blk-crypto. That would simplify ext4 and f2fs quite a bit, as they'd then have just one file contents encryption code path to support. Also, blk-crypto "just works" with large folios, whereas the fs-layer code doesn't support large folios yet. But that will only work if blk-crypto-fallback continues to support all block devices. So, effectively you are advocating for keeping the fs-layer file contents encryption code in ext4 and f2fs forever? - Eric
