On Wed, 5 Nov 2025, Benjamin Marzinski wrote:
> > @@ -3762,6 +3766,11 @@ static void crypt_io_hints(struct dm_tar
> > if (ti->emulate_zone_append)
> > limits->max_hw_sectors = min(limits->max_hw_sectors,
> > BIO_MAX_VECS <<
> > PAGE_SECTORS_SHIFT);
> > +
> > + limits->atomic_write_hw_unit_max = min(limits->atomic_write_hw_unit_max,
> > + BIO_MAX_VECS << PAGE_SHIFT);
> > + limits->atomic_write_hw_max = min(limits->atomic_write_hw_max,
> > + BIO_MAX_VECS << PAGE_SHIFT);
> > }
>
> Do we need to cap these limits, instead of just accepting the underlying
> device limits?
BIO_MAX_VECS << PAGE_SHIFT is the hard limit for the size of any write
(atomic or non-atomic) in dm-crypt. dm-crypt cannot support larger writes
by design.
If non-atomic write is larger than BIO_MAX_VECS << PAGE_SHIFT, dm-crypt
splits it using dm_accept_partial_bio. But atomic writes cannot be split,
so we need to inform the upper layer to not sent larger bios.
> Neither of them are really used for IO.
> atomic_write_unit_max, which is used for IO, will already get a capped
> value from atomic_write_hw_unit_max in
> blk_atomic_writes_update_limits(). And capping atomic_write_hw_max seems
> wrong, since atomic_write_hw_max == UINT_MAX is used
> blk_validate_atomic_write_limits() to indicate that atomic writes were
> never set up, because no underlying device supported them. I don't think
> these caps will actually break things, but in my mind they make some
> already confusing limits even more confusing.
>
> Or am I missing some reason why this is needed?
>
> -Ben
How do you think we should modify the limits, to make sure that atomic
write size is capped at BIO_MAX_VECS << PAGE_SHIFT?
Mikulas
