On Wed, Jun 11, 2025 at 09:46:31AM +0900, Damien Le Moal wrote: > On 6/11/25 8:18 AM, Keith Busch wrote: > > > > I think you could just prep the encryption at the point the bio is split > > to its queue's limits, and then all you need to do after that is ensure > > the limits don't exceed what the fallback requires (which appears to > > just be a simple segment limitation). It looks like most of the bio > > based drivers split to limits already. > > Nope, at least not DM, and by that, I mean not in the sense of splitting BIOs > using bio_split_to_limits(). The only BIOs being split are "abnormal" ones, > such as discard. > > That said, DM does split the BIOs through cloning and also has the "accept > partial" thing, which is used in many places and allows DM target drivers to > split BIOs as they are received, but not necessarilly based on the device queue > limits (e.g. dm-crypt splits reads and writes using an internal > max_read|write_size limit). > > So inline crypto on top of a DM/bio-based device may need some explicit > splitting added in dm.c (__max_io_len() maybe ?). Ah, thanks for pointing that out! In that case, could we have dm consider the bio "abnormal" when bio_has_crypt_ctx(bio) is true? That way it does the split-to-limits for these, and dm appears to do that action very early before its own split/clone actions on the resulting bio.
