On Thu, 16 May 2024, Ming Lei wrote: > On Wed, May 15, 2024 at 03:28:11PM +0200, Mikulas Patocka wrote: > > If we allocate a bio that is larger than NVMe maximum request size, attach > > integrity metadata to it and send it to the NVMe subsystem, the integrity > > metadata will be corrupted. > > > > Splitting the bio works correctly. The function bio_split will clone the > > bio, trim the iterator of the first bio and advance the iterator of the > > second bio. > > > > However, the function rq_integrity_vec has a bug - it returns the first > > vector of the bio's metadata and completely disregards the metadata > > iterator that was advanced when the bio was split. Thus, the second bio > > uses the same metadata as the first bio and this leads to metadata > > corruption. > > Wrt. NVMe, inside blk_mq_submit_bio(), bio_integrity_prep() is called after > bio is split, ->bi_integrity is actually allocated for every split bio, so I > am not sure if the issue is related with bio splitting. Or is it related > with DM over NVMe? I created a dm-crypt patch that stores autenticated data in the bio integrity field: https://patchwork.kernel.org/project/linux-block/patch/703ffbcf-2fa8-56aa-2219-10254af26ba5@xxxxxxxxxx/ And that patch needs this bugfix. Mikulas > However, rq_integrity_vec() may not work correctly in case of bio merge. > > > Thanks, > Ming >
