On Tue, Jun 16, 2026 at 08:05:53AM -0700, Keith Busch wrote:
> For DM_IO_BIO requests, do_region() built each destination bio by walking
> the source bio's biovec and re-adding the pages one at a time, tracking
> the remaining transfer in sectors.

Thanks Keith, this clears the dm-mirror hang for me.

I reproduced the original regression in a nested-QEMU harness: an LVM
legacy mirror LV (lvcreate --type mirror -m1, core log) on virtio-blk
PVs, used as the backing disk of a nested guest that issues misaligned
O_DIRECT reads via virtio-blk with cache=none,aio=native.

Without this series, on v7.1-rc7 (424280953322), the mirror read path
splats and then wedges:

  device-mapper: raid1: Mirror read failed from 252:0. Trying
alternative device.
  WARNING: block/bio.c:1044 at bio_add_page+0x108/0x200, CPU#1: kworker/1:1
  Workqueue: kmirrord do_mirror
  RIP: 0010:bio_add_page+0x108/0x200

kmirrord then stays stuck in do_mirror and the I/O never completes (the
guest hangs indefinitely).

With 1/2 and 2/2 applied on the same base, the WARN is gone, kmirrord no
longer wedges, the array is not degraded, and the misaligned O_DIRECT
read now completes normally instead of hanging. The --type raid1 (dm-raid
on md/raid1) variant of the same test is also clean.


On Wed, Jun 17, 2026 at 9:59 AM Dr. David Alan Gilbert
<[email protected]> wrote:
>
> * Keith Busch ([email protected]) wrote:
> > On Wed, Jun 17, 2026 at 04:44:35PM +0000, Dr. David Alan Gilbert wrote:
> > > (It's a bit scary you're having to go around quite
> > > a few places and make similar fixes; I assume there
> > > are others that do similar things).
> >
> > Yes, I understand that. I'm looking into a common way to validate this.
> > The md raid doesn't have this problem because they always call
> > bio_split_to_limits() first, but that's not an optimal thing to do for
> > dm raid in the normal read/write path, so perhaps a common checker needs
> > to happen generically in the block layer. Yeah, I know I removed the
> > previous higher level validation ... I'll try find something less costly
> > than what we had before.
>
> OK, thanks again
> (and to Thomas for gluing my query to those other two which got this
> moving!)
>
> Dave.
> --
>  -----Open up your eyes, open up your mind, open up your code -------
> / Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \
> \        dave @ treblig.org |                               | In Hex /
>  \ _________________________|_____ http://www.treblig.org   |_______/

Reply via email to