On Wed, Jul 08, 2026 at 07:24:14PM -0400, Benjamin Marzinski wrote: > On Tue, Jul 07, 2026 at 03:44:54PM -0400, Mike Snitzer wrote: > > On Mon, Jul 06, 2026 at 02:52:33PM -0600, Keith Busch wrote: > > > On Wed, Jun 24, 2026 at 01:14:03PM +0200, Mikulas Patocka wrote:
> > So where does dm-raid1 and dm-crypt stand relative to these DIO memory > > alignment changes? Inferring they are pretty exposed. > > > > > > BTW. I think that blk_path_error should also test for BLK_STS_INVAL and > > > > return false, otherwise, dm-multipath would be suffering from this bug > > > > too. Ben, could you test it? > > > > > > Good point. > > > > Would appreciate knowing if multipath exposed too. > > I can't make it happen. I can reproduce this using dm-mirror, but when I > try with dm-multipath, it fails with BLK_STS_INVAL before it ever makes > it into the request layer. > > blk_mq_submit_bio() -> __bio_split_to_limits() -> bio_split_rw() -> > bio_split_rw_at() -> bio_split_io_at() > > bio_split_io_at() checks the bio_vec alignment and fails with -EINVAL, > causing the bio to get failed. However, as a general issue, I don't believe it's impossible to have an unaligned bio_vec that returns false for bio_may_need_split(), so that the splitting code will never get run. But if this is already getting fixed earlier in the bio code, then the point is kind of moot. In reference to changing blk_path_error(), multipath should only be passing down requests that are valid on any of its paths, so it seems reasonable to make the case that BLK_STS_INVAL is not a path error. But if we are going to be checking the bios early against multipath's limits, then it seems like the only reason we would get a BLK_STS_INVAL is that multipath's limits don't work with the underlying path's. That would likely mean there was a limit stacking bug, and who knows whether another path would work better. -Ben > > > > Thanks, > > Mike
