Re: [PATCH 06/13] blk-crypto: support data units larger than a page

[sashiko-bot@kernel.org]

> blk-crypto-fallback requires each data unit to be contained in a single
> bio_vec, and fails a bio with a larger data unit with BLK_STS_INVAL.
> fscrypt uses the filesystem block size as its data unit size, so
> encrypted files are unusable on filesystems with a block size larger
> than the page size; the write failure is silent and loses the data.
> 
> Since commit 5acc6f649a68 ("fscrypt: Always use blk-crypto for
> contents on block-based filesystems") there is no fs-layer path left.
> Fix this by describing a data unit by one bio_vec per page: data units
> that fit keep using the bio_vec and the scatterlists in the data unit
> context, and larger ones get arrays from the new blk_crypto_du_ctx_pool.
> 
> The pool is a mempool backed by a dedicated slab cache, as kmalloc()
> would round the element size up to the next power of two.  It is set
> up when a key with such a data unit size is first used, and one array
> is reused for all data units of a bio.
> 
> A data unit must start at a data unit boundary (a page boundary for a
> larger one), and the accepted data unit sizes grow to the number of
> pages that fit in one encrypted bio, rounded down to a power of two.
> An encrypted bio can run out of room before the source bio ends; free
> its unused bounce pages with the new blk_crypto_free_enc_pages().
> 
> One crypto request per data unit is kept, so the ciphertext of data
> units that fit in a page is unchanged, and larger data units produce
> the same ciphertext as inline encryption hardware.
> 
> Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261011170958.1759230-1-libaokun@linux.alibaba.com?part=6