Re: [PATCH v6 01/43] fscrypt: add per-extent encryption support

[Eric Biggers <ebiggers@kernel.org>]

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