On 05/11/2025 17:39, Mikulas Patocka wrote:
Regarding the first patch - note that the device mapper stack may be
arbitrarily reconfigured, so it is possible that REQ_ATOMIC bio may be
sent to a target that doesn't support atomic writes - and this could
trigger the "BUG_ON(bio->bi_opf & REQ_ATOMIC);".
When reconfigured, the dm device request queue limits are re-evaluated, right?
It may or may not be re-evaluated. If you stack LVM volume group on the
top of another LVM volume group, and if you change something in the lower
volume group, the upper group has no way of finding out that the
underlying physical volumes (which are logical volumes on the lower group)
were reconfigured.
sure
Similarly, if you stack dm-crypt on the top of a logical volume and change
the limits of the logical volume, dm-crypt has no way to find you that the
underlying logical volume was reconfigured.
Sure, and I don't know what really can be done about that.
But I am interested in if extent a vg by adding another device - would
the limits of a lv be updated? I think that it would.
There is also time-to-check - vs - time-to-use race condition. Someone may
see that a device has non-zero atomic_write_hw_max, construct an atomic
write bio, the device could be reconfigured after the bio was contructed
and before the bio was dispatched - and the atomic bio would be sent to a
dm target that is not expecting it.
Sure, but the good news is that we have checks in the block stack for
this, i.e. if dm submits a bio with REQ_ATOMIC to a device which doesn't
support atomic writes, then the block stack will reject it. The physical
device will also reject it.
Thanks,
John
