On Wed, Apr 22, 2026 at 10:17:40AM +0200, Daniel Vacek wrote:
> > > +/**
> > > + * fscrypt_mergeable_extent_bio() - test whether data can be added to a
> > > bio
> > > + * @bio: the bio being built up
> > > + * @ei: the fscrypt_extent_info for this extent
> > > + * @next_lblk: the next file logical block number in the I/O
> > > + *
> > > + * When building a bio which may contain data which should undergo inline
> > > + * encryption (or decryption) via fscrypt, filesystems should call this
> > > function
> > > + * to ensure that the resulting bio contains only contiguous data unit
> > > numbers.
> > > + * This will return false if the next part of the I/O cannot be merged
> > > with the
> > > + * bio because either the encryption key would be different or the
> > > encryption
> > > + * data unit numbers would be discontiguous.
> > > + *
> > > + * fscrypt_set_bio_crypt_ctx_from_extent() must have already been called
> > > on the
> > > + * bio.
> > > + *
> > > + * This function isn't required in cases where crypto-mergeability is
> > > ensured in
> > > + * another way, such as I/O targeting only a single file (and thus a
> > > single key)
> > > + * combined with fscrypt_limit_io_blocks() to ensure DUN contiguity.
> > > + *
> > > + * Return: true iff the I/O is mergeable
> > > + */
> > > +bool fscrypt_mergeable_extent_bio(struct bio *bio,
> > > + const struct fscrypt_extent_info *ei,
> > > + u64 next_lblk)
> > > +{
> > > + const struct bio_crypt_ctx *bc = bio->bi_crypt_context;
> > > + u64 next_dun[BLK_CRYPTO_DUN_ARRAY_SIZE] = { next_lblk };
> > > +
> > > + if (!ei)
> > > + return true;
> > > + if (!bc)
> > > + return true;
> > > +
> > > + /*
> > > + * Comparing the key pointers is good enough, as all I/O for each
> > > key
> > > + * uses the same pointer. I.e., there's currently no need to
> > > support
> > > + * merging requests where the keys are the same but the pointers
> > > differ.
> > > + */
> > > + if (bc->bc_key != ei->prep_key.blk_key)
> > > + return false;
> > > +
> > > + return bio_crypt_dun_is_contiguous(bc, bio->bi_iter.bi_size,
> > > next_dun);
> > > +}
> > > +EXPORT_SYMBOL_GPL(fscrypt_mergeable_extent_bio);
> >
> > Similar to fscrypt_set_bio_crypt_ctx_from_extent(). The copy-pasted
> > comment needs to be updated to remove no-longer-relevant information
> > specific to per-file encryption and correctly reflect per-extent
> > encryption. The DUN needs to be calculated correctly for sub-block data
> > units or else the combination of the two needs to be unsupported.
>
> The DUN is fixed as per above. Regarding the comment, it looks quite
> valid to me. What exactly would you like to change?
It's now been a while since I was looking at this, but looking at it
again now, at least the following parts are incorrect:
"the next file logical block number in the I/O"
"I/O targeting only a single file (and thus a single key)"
It's actually the block number in the *extent*. And it's a single key
only when the I/O targets a single *extent*.
- Eric
