mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Garry <john.garry@linux.dev>
To: Tal Zussman <tz2294@columbia.edu>, Jens Axboe <axboe@kernel.dk>,
	Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/2] iomap: remove the atomic write length check in iomap_dio_bio_iter_one()
Date: Mon, 9 Nov 2026 18:44:34 +0000	[thread overview]
Message-ID: <4022d4f9-5e2e-45d1-b9b8-208c80f82ecf@linux.dev> (raw)
In-Reply-To: <c27b9521-7c4f-41ff-88f8-55313b5f395c@columbia.edu>

On 11/9/26 18:34, Tal Zussman wrote:
> 
> 
> On 11/8/26 12:06 PM, John Garry wrote:
>> On 11/8/26 04:24, Tal Zussman wrote:
>>> bio_iov_iter_get_pages() and bio_iov_iter_bounce_write() now fail a
>>> REQ_ATOMIC bio that doesn't cover the whole iterator, so the bio here
>>> always covers iomap_length() and the check can't trigger. Remove the
>>> check.
>>>
>>> Suggested-by: John Garry <john.garry@linux.dev>
>>> Link: https://lore.kernel.org/all/82978d5c-3e08-48e9-bf0a-7913e1cd0507@linux.dev/
>>> Signed-off-by: Tal Zussman <tz2294@columbia.edu>
>>
>> Reviewed-by: John Garry <john.garry@linux.dev>
>>
> 
> Thanks!
> 
>> This looks ok. But I am just thinking that a CoW-based atomic write does
>> not have the single bio restriction, so we don't need to fail the atomic
>> in this case. However, we should have consistent rules for iovec's
>> whether it's a block device or regular file for ext4 or xfs, so this
>> makes sense.
>>
>> thanks
>>
>> BTW, you could be a real hero and add an xfstests case for this also.
>>
> 
> What specifically would you want to see tested? I can do an atomic write with
> a partially unmapped buffer, with and without stable writes, and check that it
> fails and that nothing is written.

Just something similar to the blktests case which you added.

BTW, have you tested this partially-unmapped case for CoW-based atomics 
on xfs? You can just do that by setting atomic_wr=0

Thanks,
John

> 
>>> ---
>>>    fs/iomap/direct-io.c | 14 --------------
>>>    1 file changed, 14 deletions(-)
>>>
>>> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
>>> index ad041ac3252a..aca7cbaea4af 100644
>>> --- a/fs/iomap/direct-io.c
>>> +++ b/fs/iomap/direct-io.c
>>> @@ -370,15 +370,6 @@ static ssize_t iomap_dio_bio_iter_one(struct iomap_iter *iter,
>>>    		goto out_put_bio;
>>>    	ret = bio->bi_iter.bi_size;
>>>    
>>> -	/*
>>> -	 * An atomic write bio must cover the complete length.  If it doesn't,
>>> -	 * error out.
>>> -	 */
>>> -	if ((op & REQ_ATOMIC) && WARN_ON_ONCE(ret != iomap_length(iter))) {
>>> -		ret = -EINVAL;
>>> -		goto out_bio_release_pages;
>>> -	}
>>> -
>>>    	if (dio->flags & IOMAP_DIO_WRITE)
>>>    		task_io_account_write(ret);
>>>    	else if ((dio->flags & IOMAP_DIO_USER_BACKED) &&
>>> @@ -393,11 +384,6 @@ static ssize_t iomap_dio_bio_iter_one(struct iomap_iter *iter,
>>>    	iomap_dio_submit_bio(iter, dio, bio, pos);
>>>    	return ret;
>>>    
>>> -out_bio_release_pages:
>>> -	if (dio->flags & IOMAP_DIO_BOUNCE)
>>> -		bio_free_folios(bio);
>>> -	else
>>> -		bio_release_pages(bio, false);
>>>    out_put_bio:
>>>    	bio_put(bio);
>>>    	return ret;
>>>
>>
> 


      reply	other threads:[~2026-11-09 18:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08  4:24 [PATCH 0/2] block: fail short atomic bounce bios in bio_iov_iter_bounce_write() Tal Zussman
2026-11-08  4:24 ` [PATCH 1/2] block: fail a short atomic bounce " Tal Zussman
2026-11-08 17:13   ` John Garry
2026-11-09 18:27     ` Tal Zussman
2026-11-09 18:41       ` John Garry
2026-11-08  4:24 ` [PATCH 2/2] iomap: remove the atomic write length check in iomap_dio_bio_iter_one() Tal Zussman
2026-11-08 17:06   ` John Garry
2026-11-09 18:34     ` Tal Zussman
2026-11-09 18:44       ` John Garry [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4022d4f9-5e2e-45d1-b9b8-208c80f82ecf@linux.dev \
    --to=john.garry@linux.dev \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=tz2294@columbia.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®