Re: [PATCH 1/2] block: Make __submit_bio_noacct() preserve the bio submission order

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Jun 11, 2025 at 05:40:31AM +0200, Christoph Hellwig wrote:
> On Tue, Jun 10, 2025 at 05:18:03PM -0600, Keith Busch wrote:
> > I think you could just prep the encryption at the point the bio is split
> > to its queue's limits, and then all you need to do after that is ensure
> > the limits don't exceed what the fallback requires (which appears to
> > just be a simple segment limitation). It looks like most of the bio
> > based drivers split to limits already.
> 
> I'm still a bit confused about the interaction of block-crypto and
> stacking drivers.  For native support you obviously always want to pass
> the crypt context down to the lowest level hardware driver, and dm
> has code to support this.  But if you stacking driver is not dm, or
> the algorithm is not supported by the underlying hardware it looks
> like we might still be able to run the fallback for a stacking
> driver.  Or am I missing something here?  Eric/Bart: any chance to
> get blktests (or xfstets if that's easier to wire up) to exercise all
> these corner cases?

blk-crypto-fallback runs at the top layer, so yes it's different from native
inline encryption support where the encryption is done at the bottom.  (But the
results are the same from the filesystem's perspective, since native support
only gets passed through and used when it would give the expected result.)

If it helps, blk-crypto-fallback can be exercised by running the "encrypt" group
of xfstests on ext4 or f2fs with "inlinecrypt" added to the mount options.
These include tests that the data on-disk is actually encrypted correctly.

But that probably doesn't help much here, where the issue is with bio splitting.

It's been a while since I looked at blk-crypto-fallback.  But the reason that it
does splitting is because it has to replace the data with encrypted data, and it
allocates encrypted bounce pages individually which each needs its own bio_vec.
Therefore, if the bio is longer than BIO_MAX_VECS pages, it has to be split.

If the splitting to stay within BIO_MAX_VECS pages could be done before
blk-crypto-fallback is given the bio instead, that should work fine too.

Just keep in mind that blk-crypto-fallback is meant to work on any block device
(even ones that don't have a crypto profile, as the profile is just for the
native support).  So we do need to make sure it always gets invoked when needed.

- Eric