On Thu, 6 Nov 2025, John Garry wrote:
> On 06/11/2025 12:06, Mikulas Patocka wrote:
> > > 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?
>
> The atomic write size is limited elsewhere, specifically
> blk_atomic_writes_update_limits() - the limit there is quite similar (to what
> is added in this updated patch). So I don't think that we need to do anything
> special in dm-crypt, as that block limit is already tighter.
>
> I suppose that this code can be kept with a comment (saying that it is
> unnecessary, but safer to keep). Or we can just drop the code and add a
> comment (saying that we don't need to limit here, as it is done elsewhere).
>
> Thanks,
> John
What if someone creates a hypothetical device that supports atomic writes
larger than BIO_MAX_VECS << PAGE_SHIFT? I think, we should limit it.
Mikulas
