On Thu, 23 Apr 2026 at 00:54, Eric Biggers <[email protected]> wrote: > 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*.
Yeah, I fixed the block number comment with the change to the `pos` offset. That one is clear. I'll amend the rest. Thank you very much, Eric. --nX > - Eric
