On Tue, Apr 12, 2022 at 04:52:40PM -0400, Mike Snitzer wrote: > On Tue, Apr 12 2022 at 4:56P -0400, > Ming Lei <ming.lei@xxxxxxxxxx> wrote: > > > The current DM codes setup ->orig_bio after __map_bio() returns, > > and not only cause kernel panic for dm zone, but also a bit ugly > > and tricky, especially the waiting until ->orig_bio is set in > > dm_submit_bio_remap(). > > > > The reason is that one new bio is cloned from original FS bio to > > represent the mapped part, which just serves io accounting. > > > > Now we have switched to bdev based io accounting interface, and we > > can retrieve sectors/bio_op from both the real original bio and the > > added fields of .sector_offset & .sectors easily, so the new cloned > > bio isn't necessary any more. > > > > Not only fixes dm-zone's kernel panic, but also cleans up dm io > > accounting & split a bit. > > You're conflating quite a few things here. DM zone really has no > business accessing io->orig_bio (dm-zone.c can just as easily inspect > the tio->clone, because it hasn't been remapped yet it reflects the > io->origin_bio, so there is no need to look at io->orig_bio) -- but > yes I clearly broke things during the 5.18 merge and it needs fixing > ASAP. You can just consider the cleanup part of this patches, :-) 1) no late assignment of ->orig_bio, and always set it in alloc_io() 2) no waiting on on ->origi_bio, especially the waiting is done in fast path of dm_submit_bio_remap(). 3) no split for io accounting Thanks, Ming -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
