On Mon, Apr 27, 2026 at 01:23:27AM -0400, Benjamin Marzinski wrote: > On Fri, Apr 10, 2026 at 06:40:30AM -0700, Linlin Zhang wrote: > > From: Eric Biggers <[email protected]> > > + /* > > + * Since we've added an encryption context to the bio and > > + * blk-crypto-fallback may be needed to process it, it's necessary to > > + * use the fallback-aware bio submission code rather than > > + * unconditionally returning DM_MAPIO_REMAPPED. > > + * > > + * To get the correct accounting for a dm target in the case where > > + * __blk_crypto_submit_bio() doesn't take ownership of the bio (returns > > + * true), call __blk_crypto_submit_bio() directly and return > > + * DM_MAPIO_REMAPPED in that case, rather than relying on > > + * blk_crypto_submit_bio() which calls submit_bio() in that case. > > + */ > > + if (__blk_crypto_submit_bio(bio)) > > This will still double account for fallback writes (which call > submit_bio() on the encrypted bios, and return DM_MAPIO_SUBMITTED here).
Just to clarify, I'm talking about the vmstats accounting. The IO originally gets accounted by submit_bio() when the bio is submitted to the dm device. For actual inline encryption and fallback reads, dm will submit the bio to the underlying device using submit_bio_noacct() to avoid double-counting the IO. For fallback writes, __blk_crypto_submit_bio() will submit the encrypted bios to the underlying device with submit_bio(). This adds the IO sectors again, even though it's the same IO, only encrypted now. -Ben > > -Ben > > > + return DM_MAPIO_REMAPPED; > > + return DM_MAPIO_SUBMITTED; > > +} >
