From: Stefan Hajnoczi <stefanha@redhat.com>
To: Hanna Czenczek <hreitz@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org,
Kevin Wolf <kwolf@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [PATCH v2] block: Fix pad_request's request restriction
Date: Mon, 17 Jul 2023 16:32:06 -0400 [thread overview]
Message-ID: <20230717203206.GA461188@fedora> (raw)
In-Reply-To: <20230714085938.202730-1-hreitz@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
On Fri, Jul 14, 2023 at 10:59:38AM +0200, Hanna Czenczek wrote:
> bdrv_pad_request() relies on requests' lengths not to exceed SIZE_MAX,
> which bdrv_check_qiov_request() does not guarantee.
>
> bdrv_check_request32() however will guarantee this, and both of
> bdrv_pad_request()'s callers (bdrv_co_preadv_part() and
> bdrv_co_pwritev_part()) already run it before calling
> bdrv_pad_request(). Therefore, bdrv_pad_request() can safely call
> bdrv_check_request32() without expecting error, too.
>
> In effect, this patch will not change guest-visible behavior. It is a
> clean-up to tighten a condition to match what is guaranteed by our
> callers, and which exists purely to show clearly why the subsequent
> assertion (`assert(*bytes <= SIZE_MAX)`) is always true.
>
> Note there is a difference between the interfaces of
> bdrv_check_qiov_request() and bdrv_check_request32(): The former takes
> an errp, the latter does not, so we can no longer just pass
> &error_abort. Instead, we need to check the returned value. While we
> do expect success (because the callers have already run this function),
> an assert(ret == 0) is not much simpler than just to return an error if
> it occurs, so let us handle errors by returning them up the stack now.
>
> Reported-by: Peter Maydell <peter.maydell@linaro.org>
> Fixes: 18743311b829cafc1737a5f20bc3248d5f91ee2a
> ("block: Collapse padded I/O vecs exceeding IOV_MAX")
> Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
> ---
> v2:
> - Added paragraph to the commit message to express explicitly that this
> patch will not change guest-visible behavior
> - (No code changes)
> ---
> block/io.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Thanks, applied to my block-next tree:
https://gitlab.com/stefanha/qemu/commits/block-next
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2023-07-17 20:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 8:59 [PATCH v2] block: Fix pad_request's request restriction Hanna Czenczek
2023-07-17 20:32 ` Stefan Hajnoczi [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=20230717203206.GA461188@fedora \
--to=stefanha@redhat.com \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.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.