On Wed, 5 Nov 2025, John Garry wrote:
> > 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.
Yes, they 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.
Yes - but the block layer checks the bio without preventing device mapper
table swap.
So, the block layer may find out that a device supports atomic writes,
pass the bio through to dm, dm table may be reloaded and the bio would be
sent to a target that doesn't expect it.
You must do the check inside the RCU read region to make sure that the
dm table can't be swapped underneath.
Mikulas
> Thanks,
> John
>
