Re: [PATCH v2 2/2] block: Rework splitting of encrypted bios

[Eric Biggers <ebiggers@kernel.org>]

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