Re: [PATCH v2 2/3] dm-inlinecrypt: add target for inline block device encryption

[Benjamin Marzinski <bmarzins@redhat.com>]

On Wed, Apr 29, 2026 at 11:25:04AM -0400, Benjamin Marzinski wrote:
> On Wed, Apr 29, 2026 at 08:34:00PM +0800, Linlin Zhang wrote:
[...]
> > 
> > Thanks for the suggestions.
> > 
> > Adding a bool need_acct parameter to __blk_crypto_submit_bio() would require
> > updating all existing callers, which feels rather intrusive given that the
> > accounting issue only affects the blk‑crypto fallback write slow‑path. I’m a
> > bit concerned that this would broaden the scope of the change more than
> > necessary for the problem at hand.
> 
> I get your concern, and I'd like a second opinion on how much we should
> care about this, but it doesn't look like there are many other callers
> that would be effected here. The only existing caller of
> __blk_crypto_submit_bio() is blk_crypto_submit_bio(), which would just
> call it with "need_acct=true". Looking at the code path below
> __blk_crypto_submit_bio() that would need to change for submitting the
> bios:
> 
> __blk_crypto_submit_bio() is the only caller of
> blk_crypto_fallback_bio_prep()
> 
> blk_crypto_fallback_bio_prep() is the only caller of
> blk_crypto_fallback_encrypt_bio().
> 
> blk_crypto_fallback_encrypt_bio() is the only caller of
> __blk_crypto_fallback_encrypt_bio(), which is the function that would
> need to choose between submit_bio() and submit_bio_noacct().
> 
> Doing this would change the crypto API (by necessity, since we're adding
> a new argument to __blk_crypto_submit_bio() for stacking devices to
> use), and it is adds a extra argument to a number of functions, just to
> handle this corner case. But it is still a relatively contained change.

Having discussed this a bit, I'm fine with leaving this as a TODO for
now. If anyone wants to chime in with an opinion on how acceptable it
would be to add a new bio flag for skipping accounting, that would be
great.

-Ben