From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
To: Tal Zussman <tz2294@columbia.edu>
Cc: linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
John Garry <john.garry@linux.dev>
Subject: Re: [PATCH blktests v4] block/053: add a torn atomic write test for block devices
Date: Tue, 10 Nov 2026 20:19:43 +0900 [thread overview]
Message-ID: <avL9qcoPV384yOC2@shinmob> (raw)
In-Reply-To: <20261030-blkdev-fixes-tests-v4-1-d8d18808e965@columbia.edu>
On Oct 30, 2026 / 19:26, Tal Zussman wrote:
> A block device atomic write is a hardware atomic write, submitted as a
> single bio, so when its buffer can't be fully pinned, the direct I/O
> path has to fail the write rather than submit the pinned part.
> Otherwise, it submits what was pinned with REQ_ATOMIC set and leaves
> the rest to the buffered fallback, tearing the write at the pin
> boundary.
>
> This is a regression test for that issue, fixed by commit 73a0ff6030af
> ("block: fail a short atomic pin in bio_iov_iter_get_pages()").
>
> Issue a two-page pwritev2() with RWF_ATOMIC to a scsi_debug device with
> atomic_wr=1 from a buffer whose last page is PROT_NONE, so that pinning
> the buffer stops one page short. Check with statx() that the device
> supports an atomic write of that size, then check that the write fails
> with EINVAL and that the range still reads back as the old data.
>
> Two pages is the smallest write that leaves one page unpinnable, and
> atomic_wr_max_length=256 raises the atomic write unit max to 128K so
> that two pages fit for any page size up to 64K.
>
> Signed-off-by: Tal Zussman <tz2294@columbia.edu>
Thank you, I applied it.
prev parent reply other threads:[~2026-11-10 11:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 23:26 [PATCH blktests v4] block/053: add a torn atomic write test for block devices Tal Zussman
2026-11-02 9:18 ` John Garry
2026-11-10 11:19 ` Shin'ichiro Kawasaki [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=avL9qcoPV384yOC2@shinmob \
--to=shinichiro.kawasaki@wdc.com \
--cc=hch@lst.de \
--cc=john.garry@linux.dev \
--cc=linux-block@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.