On Wed, 5 Nov 2025, John Garry wrote:
> On 05/11/2025 15:00, Mikulas Patocka wrote:
> >
> >
> > On Wed, 5 Nov 2025, John Garry wrote:
> >
> > > This small series enables atomic writes support for dm-crypt.
> > >
> > > Apart from setting DM_TARGET_ATOMIC_WRITES flag, we need to make the
> > > following changes:
> > > - limit atomic write size to dm-crypt max write size
> > > - BUG_ON() any partial completions for when REQ_ATOMIC is set
> > >
> > > John Garry (2):
> > > dm: BUG on REQ_ATOMIC in dm_accept_partial_bio()
> > > dm-crypt: enable DM_TARGET_ATOMIC_WRITES
> > >
> > > drivers/md/dm-crypt.c | 21 +++++++++++++++++++--
> > > drivers/md/dm.c | 5 +++--
> > > 2 files changed, 22 insertions(+), 4 deletions(-)
> > >
> > > --
> > > 2.43.5
> >
>
> Hi Mikulas,
>
> >
> > Thanks for the patches, I reworked them a bit.
> >
> > 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.
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.
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.
Mikulas
