From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.4 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794157588; b=dlEO9dKsYBwXXl3rlHEKXfv0STOt5ZDObpna5GqxA2LNxc9PFwhh7f/5gVOeBBqilS7e qktQ54NupvAtt1S1kpMK7NaSMN5noiURLqjYdIulC4dSUJUUChXawxZP2Rqazw+k11bHH NvQqiDkgdRRJ/m8GIsAyuEX7FUhEX0+H9EelVloultoWWReqmmNJ8rSc0gKnjGUDVgsmz R12UDa+cFT9ap43zYHdVqzSXUY3hlbayd+yBozOS8SC5g+2MNikBxK8nmPukqXzFXM9r1 FdSUqlOpoSjQMz9mPpxXsIS9ycC++a2Sg0FPjTGmMHvjWff0Cl/HR7tsev+ExAKng3g== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794157588; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Message-ID:Date:MIME-Version:User-Agent: Subject:To:Cc:References:Content-Language:From:In-Reply-To: Content-Type:Content-Transfer-Encoding; bh=IEd3jpYcDB0NK70MyV6liue2t6+43KsA976DKWNPe50=; b=E0HR4AHk/PuGPkZqh4Wo124VNqnS3uJrZYwWXS43dTT755zJi/LB5K0PFs5niyti1cND hRlTvRUqJlg3vCt7/yRYf3SffK7MvYEQ5xdThZ214FssG5ugsGXMFRogo7tnAPqOayg8y HIAItuRpgOg2JtxXehqqSBrNxiFrsbZP717tkBB1YYzeFFI5RarEAEHRNiboqOSGesgsZ uZw9A3njP9mx2prh5XjKTIj80SiFX2YwEUgZQD0AAHKouMsdbjTH9nhP6is4Sh6JBRTMg RxK81q9Vp2IOTpABd++hN6uxWxKyHsImxisLQNLO5pE8GSmTFQibmBGbqz5MJR9CbOA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=V9MbJkdE; arc=none smtp.remote-ip=91.218.175.4 Received: from mta0.migadu.com (out-4.mta0.migadu.com [91.218.175.4]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D897606A321 for ; Sun, 8 Nov 2026 17:06:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 9D897606A321 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=V9MbJkdE X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=JkojSWXaqiTE4m7MsVL3k+FVelopN8MwdLMIVVaO17Q=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1794157584; v=1; x=1794762384; b=V9MbJkdENmHNBeEfotWF+AMWMIuReMh3cMogaPPYpCteLNr+wC4V4KGEcKLFKMuaUjS7dHr/ K3ddnXkXT3nWGA9mOrrn7vgz69jBW10m45EYdgFgK++emJu4r7GNjQhBNSwqNOvXs2uzQk34NmS fcetf0UxKuqHf3DfXX0TdLSY= X-Envelope-To: linux-kernel@vger.kernel.org Received: by mta11.migadu.com with ESMTPS id 89021f10fe198751; Sun, 08 Nov 2026 17:06:24 +0000 X-Mizu-Trace-ID: 89021f10fe198751 X-Migadu-Flow: FLOW_OUT Message-ID: <3fc46788-d86d-44c5-8606-385d96fede4d@linux.dev> Date: Sun, 8 Nov 2026 17:06:21 +0000 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] iomap: remove the atomic write length check in iomap_dio_bio_iter_one() To: Tal Zussman , Jens Axboe , Christian Brauner Cc: Christoph Hellwig , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <20261107-blkdev-atomic-bounce-v1-0-f66344262096@columbia.edu> <20261107-blkdev-atomic-bounce-v1-2-f66344262096@columbia.edu> Content-Language: en-US From: John Garry In-Reply-To: <20261107-blkdev-atomic-bounce-v1-2-f66344262096@columbia.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > Link: https://lore.kernel.org/all/82978d5c-3e08-48e9-bf0a-7913e1cd0507@linux.dev/ > Signed-off-by: Tal Zussman Reviewed-by: John Garry 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. > --- > 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; >