Re: [PATCH 2/2] dm-raid1: don't fail the mirror for invalid I/O errors

[Benjamin Marzinski <bmarzins@redhat.com>]

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