From: Mike Snitzer <snitzer@kernel.org>
To: linux-nfs@vger.kernel.org, linux-block@vger.kernel.org
Cc: dm-devel@lists.linux.dev, axboe@kernel.dk, cel@kernel.org,
jlayton@kernel.org, david.flynn@hammerspace.com
Subject: Re: [PATCH 0/4] block, nfsd: fixes for sub-sector bvec direct I/O
Date: Tue, 8 Sep 2026 12:36:58 -0400 [thread overview]
Message-ID: <aqA5qgfUTbNi0nHJ@kernel.org> (raw)
In-Reply-To: <20260908163448.30841-1-snitzer@kernel.org>
Apologies for the git-send-email misfire.. still not sure what
happened, but will sort it out for future.
On Tue, Sep 08, 2026 at 12:34:35PM -0400, Mike Snitzer wrote:
> While qualifying NFSD's NFSD_IO_DIRECT write path with byte-level data
> verification, it was found that the ITER_BVEC payloads nfsd submits
> expose silent data corruption in two bio-based block drivers and
> two defects in nfsd itself. Example problematic payloads is the first
> fragment starts mid-page because the RPC header precedes it in the
> receive buffer, and fragment lengths need not be sector multiples.
> bio_iov_bvec_set() passes such an array to the queue as-is; nothing
> below it validates per-bvec sector alignment.
>
> Patches 1-2 fix silent corruption (write completes successfully, data
> lands wrong) and are stable candidates:
>
> - brd re-derives each segment's device position from
> bio->bi_iter.bi_sector, which bio_advance_iter_single() advances by
> whole sectors only, so a sub-sector segment length skews everything
> that follows.
>
> - zram hardwires is_partial_io() to false on 4K-page kernels, sending
> sub-page bvecs down a whole-page path that ignores bv_offset/bv_len
> entirely, and has the same sector-cursor skew.
>
> Both are verified with a synthetic-bio reproducer (stamped pattern,
> write, read back, compare) across mid-page and page-aligned
> geometries.
>
> Patches 3-4 fix nfsd: the filecache never fetches DIO alignment
> attributes on the supplied-file acquire branch, so every WRITE to a
> file created via NFSv4 OPEN(CREATE) is refused direct I/O for the
> file's cached lifetime; and nfsd's statx-based DIO gate is weaker than
> bio_split_io_at()'s split-time checks, so an admitted iterator can
> still be rejected by the block layer -- retry the segment buffered
> instead of failing a valid WRITE with NFS4ERR_INVAL.
>
> One open question for the iomap/block maintainers: should ITER_BVEC
> direct I/O with sub-sector bvec boundaries be validated or bounced
> centrally rather than trusted to every driver's iteration? An audit
> of in-tree bio-based drivers found the same bi_sector-derived position
> pattern in dm-io, dm-log-writes, dm-writecache (pmem path) and
> dm-integrity -- unreachable through nfsd today only because dm queues
> advertise dma_alignment >= 511, which nfsd's alignment gate refuses.
>
> Tested with the reproducer matrix on brd, zram and nvme-loop at 4K and
> 16K page size (aarch64) and 4K (x86_64), plus 30-connection NFS write
> rigs comparing source against export byte-for-byte: clean with the
> fixes, corrupting or erroring without them.
>
> Mike Snitzer (3):
> brd: iterate the bio by byte position, not bi_sector
> zram: handle sub-page bvec segments without corrupting data
> nfsd: fall back to buffered I/O when a direct write gets -EINVAL
>
> David Flynn (1):
> nfsd: fetch direct I/O alignment for files handed to the filecache
>
> drivers/block/brd.c | 29 +++++++++++++++++++++++------
> drivers/block/zram/zram_drv.c | 36 +++++++++++++++++------------------
> fs/nfsd/filecache.c | 4 ++--
> fs/nfsd/vfs.c | 29 +++++++++++++++++++++++++++++
> 4 files changed, 77 insertions(+), 31 deletions(-)
>
> --
> 2.52.0
next prev parent reply other threads:[~2026-09-08 16:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 16:32 [PATCH 0/4] block, nfsd: fixes for sub-sector bvec direct I/O Mike Snitzer
2026-09-08 16:32 ` [PATCH 1/4] brd: iterate the bio by byte position, not bi_sector Mike Snitzer
2026-09-08 16:34 ` [PATCH 0/4] block, nfsd: fixes for sub-sector bvec direct I/O Mike Snitzer
2026-09-08 16:34 ` [PATCH 1/4] brd: iterate the bio by byte position, not bi_sector Mike Snitzer
2026-09-08 16:34 ` [PATCH 2/4] zram: handle sub-page bvec segments without corrupting data Mike Snitzer
2026-09-08 16:34 ` [PATCH 3/4] nfsd: fetch direct I/O alignment for files handed to the filecache Mike Snitzer
2026-09-09 14:11 ` Chuck Lever
2026-09-08 16:34 ` [PATCH 4/4] nfsd: fall back to buffered I/O when a direct write gets -EINVAL Mike Snitzer
2026-09-08 18:25 ` Chuck Lever
[not found] ` <B3A1EA3A-00AA-4A56-A644-9AC77FF50CAF@hammerspace.com>
2026-09-09 13:44 ` Chuck Lever
2026-09-09 16:40 ` Mike Snitzer
2026-09-10 9:53 ` Christoph Hellwig
2026-09-08 16:34 ` [PATCH 0/4] block, nfsd: fixes for sub-sector bvec direct I/O Mike Snitzer
2026-09-08 16:34 ` [PATCH 1/4] brd: iterate the bio by byte position, not bi_sector Mike Snitzer
2026-09-08 16:34 ` [PATCH 2/4] zram: handle sub-page bvec segments without corrupting data Mike Snitzer
2026-09-08 16:34 ` [PATCH 3/4] nfsd: fetch direct I/O alignment for files handed to the filecache Mike Snitzer
2026-09-08 16:34 ` [PATCH 4/4] nfsd: fall back to buffered I/O when a direct write gets -EINVAL Mike Snitzer
2026-09-08 16:34 ` [PATCH 2/4] zram: handle sub-page bvec segments without corrupting data Mike Snitzer
2026-09-08 16:34 ` [PATCH 3/4] nfsd: fetch direct I/O alignment for files handed to the filecache Mike Snitzer
2026-09-08 16:34 ` [PATCH 4/4] nfsd: fall back to buffered I/O when a direct write gets -EINVAL Mike Snitzer
2026-09-08 16:36 ` Mike Snitzer [this message]
2026-09-08 17:48 ` [PATCH 0/4] block, nfsd: fixes for sub-sector bvec direct I/O Chuck Lever
2026-09-08 18:06 ` Mike Snitzer
2026-09-10 7:14 ` Christoph Hellwig
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=aqA5qgfUTbNi0nHJ@kernel.org \
--to=snitzer@kernel.org \
--cc=axboe@kernel.dk \
--cc=cel@kernel.org \
--cc=david.flynn@hammerspace.com \
--cc=dm-devel@lists.linux.dev \
--cc=jlayton@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/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.