All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>, Hannes Reinecke <hare@kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Paulo Alcantara <pc@manguebit.org>,
	netfs@lists.linux.dev, linux-block@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] block: Fix start and length check added to iov_iter_extract_bvecs()
Date: Wed, 26 Aug 2026 14:02:43 -0600	[thread overview]
Message-ID: <ao9GY22aAvnZUye0@kbusch-mbp> (raw)
In-Reply-To: <1864928.1787773740@warthog.procyon.org.uk>

On Wed, Aug 26, 2026 at 08:49:00PM +0100, David Howells wrote:
> Keith Busch <kbusch@kernel.org> wrote:
> 
> > iov_iter_alignment loops over all the vectors when we only need to
> > examine the current one here.
> 
> Actually, I don't think that's true.  iov_iter_extract_pages() is allowed to
> pull from multiple bio_vecs in an ITER_BVEC, for example - and if, say, the
> page in the second bio_vec is contiguous with the first, then
> iov_iter_extract_bvecs() will use it - so you still need to check bv_len on
> it.

I don't think we should be extracting bvecs for the ITER_BVEC type.
bio_iov_iter_get_pages() already doesn't. I'll look more into the
recently introduced bio_iov_iter_bounce_read() usage, as there may be an
optimization there.

But in general, yeah, it should be safe for any type. The proposal I
sent a bit ago will handle the ITER_BVEC as you've desribed.

  reply	other threads:[~2026-08-26 20:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26 18:18 [PATCH] block: Fix start and length check added to iov_iter_extract_bvecs() David Howells
2026-08-26 18:34 ` Keith Busch
2026-08-26 19:24   ` David Howells
2026-08-26 19:47     ` Keith Busch
2026-08-26 20:23       ` David Howells
2026-08-26 19:49   ` David Howells
2026-08-26 20:02     ` Keith Busch [this message]
2026-08-26 20:46 ` [PATCH v2] " David Howells
2026-08-26 20:52   ` Keith Busch
2026-08-26 20:54   ` David Howells
2026-09-02 11:27   ` Christoph Hellwig
2026-09-04  9:42     ` David Howells
2026-09-04 18:37       ` Keith Busch
2026-09-05 16:26         ` David Howells
2026-09-07  6:18           ` Christoph Hellwig
2026-09-07  6:15       ` 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=ao9GY22aAvnZUye0@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=dhowells@redhat.com \
    --cc=hare@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=netfs@lists.linux.dev \
    --cc=pc@manguebit.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.