Re: [PATCH 2/7] md/raid1: handle atomic writes that require splitting

On 23/06/2026 09:58, Abd-Alrhman Masalkhi wrote:
> On Tue, Jun 23, 2026 at 09:11 +0100, John Garry wrote:
>> On 23/06/2026 08:24, Abd-Alrhman Masalkhi wrote:
>>> If a request already requires splitting when entering
>>> raid1_write_request(), the current code allows it to proceed until it
>>> eventually reaches the split path.
>>
>> The block layer should catch invalid atomic writes in
>> submit_bio_noacct() -> blk_validate_atomic_write_op_size() before we
>> even get as far as the md atomic write handling. Having the check in
>> bio_submit_split_bioset() is really just a fail-safe for the block layer
>> not catching invalid atomic writes or the atomic writes queue limits not
>> being properly calculated.
> The request size itself satisfies the currently advertised atomic write
> limits, so blk_validate_atomic_write_op_size() allows it. The problem
> is that RAID1 may further restrict atomic writes to a single barrier
> unit via align_to_barrier_unit_end(). Therefore a request that crosses
> a barrier-unit boundary can still reach raid1_write_request() with
> max_sectors < bio_sectors(bio).
> 
> If the barrier-unit restriction should instead be advertised through the
> atomic write queue limits, 

It should. Any restrictions should be advertised up front. For the user 
to issue an atomic write which is valid according to limits, then it 
should succeed.

> then I agree the block layer could reject
> such requests earlier and the RAID1 entry check would become
> unnecessary.
> 
> However, there are also cases where max_sectors is reduced later within
> raid1_write_request(), for example when bad blocks are present on some
> mirrors (or due to other RAID1-specific constraints such as write-behind
> limits). Those reductions depend on RAID1 runtime state and mirror
> health, so they are not readily visible to the block layer during atomic
> write validation. In those cases RAID1 still needs to detect that the
> atomic write can no longer be serviced as requested and fail it
> appropriately.

Sure, and we do this. As I remember, we should return -EIO in this case.

> 
>>
>>> Along the way, the bio may instead
>>> fail due to other conditions and return a different status, even though
>>> the request was invalid as an atomic write from the beginning.
>>>