From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@meta.com>,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
dm-devel@lists.linux.dev, axboe@kernel.dk, brauner@kernel.org,
djwong@kernel.org, viro@zeniv.linux.org.uk,
stable@vger.kernel.org
Subject: Re: [PATCH 1/1] block: validate user space vectors during extraction
Date: Thu, 18 Jun 2026 15:43:46 +0200 [thread overview]
Message-ID: <20260618134346.GA2752@lst.de> (raw)
In-Reply-To: <ajPv7yOoYsR5O6kf@kbusch-mbp>
On Thu, Jun 18, 2026 at 07:17:35AM -0600, Keith Busch wrote:
> > > if (iov_iter_is_bvec(iter)) {
> > > bio_iov_bvec_set(bio, iter);
> > > +
> > > + if (mp_bvec_iter_offset(bio->bi_io_vec, bio->bi_iter) &
> > > + vec_align_mask)
> > > + return -EINVAL;
> >
> > Can you add a comment here? Especially as the bvec iter doesn't actually
> > require all individual bvecs to be aligned and I'm not entirely sure this
> > handles all case - writing down the rules might help a bit with that.
>
> The rationale is that the only iter_bvec users come from io_uring
> registered buffers, which are virtually contiguous.
There's plenty of iov_iter_bdev users, and even without poking deep I
know that two directly passed on bvecs from block-layer generated bios to
the underlying file system's direct I/O code: loop and zloop.
So we need rules on what can be passed, and preferably some way to
enforce that at least for debug builds.
next prev parent reply other threads:[~2026-06-18 13:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-17 23:32 [PATCH 0/1] direct-io: validate user space vectors during extraction Keith Busch
2026-06-17 23:32 ` [PATCH 1/1] block: " Keith Busch
2026-06-18 10:22 ` kernel test robot
2026-06-18 10:26 ` Christoph Hellwig
2026-06-18 13:17 ` Keith Busch
2026-06-18 13:43 ` Christoph Hellwig [this message]
2026-06-18 13:51 ` Keith Busch
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=20260618134346.GA2752@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.