From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexander Graf <graf@amazon.com>
Cc: "Jason Wang" <jasowangio@gmail.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org,
nh-open-source@amazon.com,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [RFC PATCH 02/12] virtio_ring: validate premapped addresses through the device's map
Date: Sun, 9 Aug 2026 18:48:34 -0400 [thread overview]
Message-ID: <20260809184247-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20260809182010.32931-3-graf@amazon.com>
On Sun, Aug 09, 2026 at 06:20:00PM +0000, Alexander Graf wrote:
> Callers that forget to handle a mapping failure may accidentally pass
> DMA_MAPPING_ERROR as target map address and we don't error out for it.
> The mapped path in vring_map_one_sg() checks the result, but the
> premapped path takes the address as given. That makes it more difficult
> to identify accidental API misuse.
Nah.
We don't spread null checks all over the place and this is the same.
>
> Run the address through the existing vring_mapping_error(), which asks
> the device's virtio_map_ops mapping_error op or dma_mapping_error(),
> warn once and return -ENOMEM when it rejects the address. Document
> where the premapped helpers expect their addresses to come from, since
> an address from any other source is indistinguishable from a valid one.
> That way an API misuse shows up at the call that made it.
Commit log does not match what doc patches do.
> Assisted-by: Kiro:claude-opus-5 checkpatch sparse
> Signed-off-by: Alexander Graf <graf@amazon.com>
> ---
> drivers/virtio/virtio_ring.c | 40 ++++++++++++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index b438dc2ce1b8..9caa4f96204f 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -499,6 +499,19 @@ static int vring_map_one_sg(const struct vring_virtqueue *vq, struct scatterlist
> if (premapped) {
> *addr = sg_dma_address(sg);
> *len = sg_dma_len(sg);
> +
> + /*
> + * The caller mapped this itself, so the map it used is the
> + * only thing that can judge the result. Ask it rather than
> + * skipping the check the mapped path performs: a caller that
> + * ignored a failed mapping would otherwise publish the
> + * reserved error value to the device.
> + */
> + if (dev_WARN_ONCE(&vq->vq.vdev->dev,
> + vring_mapping_error(vq, *addr),
> + "premapped buffer holds no valid mapping\n"))
> + return -ENOMEM;
> +
> return 0;
> }
>
> @@ -2910,6 +2923,14 @@ EXPORT_SYMBOL_GPL(virtqueue_add_outbuf);
> * @data: the token identifying the buffer.
> * @gfp: how to do memory allocations (if necessary).
> *
> + * Each entry of @sg must carry an address the caller obtained for this
> + * virtqueue: from the DMA API when virtqueue_dma_dev() returns a device, and
> + * from virtqueue_map_page_attrs() when it returns NULL, because the device
> + * then interprets every address published to it in its own terms. Only an
> + * address the map itself rejects is caught here; an address from any other
> + * source is indistinguishable from a valid one and reaches the device
> + * unchanged.
> + *
> * Caller must ensure we don't call this with other virtqueue operations
> * at the same time (except where noted).
> *
> @@ -3008,6 +3029,14 @@ EXPORT_SYMBOL_GPL(virtqueue_add_inbuf_ctx);
> * @ctx: extra context for the token
> * @gfp: how to do memory allocations (if necessary).
> *
> + * Each entry of @sg must carry an address the caller obtained for this
> + * virtqueue: from the DMA API when virtqueue_dma_dev() returns a device, and
> + * from virtqueue_map_page_attrs() when it returns NULL, because the device
> + * then interprets every address published to it in its own terms. Only an
> + * address the map itself rejects is caught here; an address from any other
> + * source is indistinguishable from a valid one and reaches the device
> + * unchanged.
I don't see what this comment gets us.
And let's not do this half hearted validation.
> + *
> * Caller must ensure we don't call this with other virtqueue operations
> * at the same time (except where noted).
> *
> @@ -3025,10 +3054,17 @@ int virtqueue_add_inbuf_premapped(struct virtqueue *vq,
> EXPORT_SYMBOL_GPL(virtqueue_add_inbuf_premapped);
>
> /**
> - * virtqueue_dma_dev - get the dma dev
> + * virtqueue_dma_dev - get the device to use for DMA API calls
> * @_vq: the struct virtqueue we're talking about.
> *
> - * Returns the dma dev. That can been used for dma api.
> + * A NULL return means this virtqueue publishes no DMA addresses: either it
> + * needs no mapping at all, or the device supplies its own virtio_map_ops and
> + * interprets every address published to it in its own terms. A caller that
> + * maps buffers itself must therefore check for NULL before using the DMA API
> + * on this virtqueue's behalf, and use virtqueue_map_page_attrs() when it is,
> + * which maps through whichever of the two the device uses.
Too verbose and repetetive. E.g. of course people who call virtqueue_dma_dev
do it to "map bufers itself".
> + *
> + * Return: the device to use for DMA API calls, or NULL when there is none.
> */
> struct device *virtqueue_dma_dev(struct virtqueue *_vq)
> {
next prev parent reply other threads:[~2026-08-09 22:48 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-09 18:19 [RFC PATCH 00/12] virtio: support devices that own their virtqueue memory Alexander Graf
2026-08-09 18:19 ` [RFC PATCH 01/12] vdpa: correct the VIRTIO_DEVICE_F_MASK example value Alexander Graf
2026-08-09 22:42 ` Michael S. Tsirkin
2026-08-09 18:20 ` [RFC PATCH 02/12] virtio_ring: validate premapped addresses through the device's map Alexander Graf
2026-08-09 22:48 ` Michael S. Tsirkin [this message]
2026-08-09 18:20 ` [RFC PATCH 03/12] virtio: add the VIRTIO_F_DMB feature bit Alexander Graf
2026-08-09 18:20 ` [RFC PATCH 04/12] virtio_pci: read the device memory buffer shared memory id Alexander Graf
2026-08-09 18:20 ` [RFC PATCH 05/12] virtio_pci: create virtqueues with the device's mapping token Alexander Graf
2026-08-09 18:20 ` [RFC PATCH 06/12] virtio: add a device memory buffer region allocator Alexander Graf
2026-08-09 22:06 ` Michael S. Tsirkin
2026-08-09 22:38 ` Michael S. Tsirkin
2026-08-10 7:57 ` Graf (AWS), Alexander
2026-08-10 8:07 ` Michael S. Tsirkin
2026-08-09 18:20 ` [RFC PATCH 07/12] virtio: locate the device memory buffer after feature negotiation Alexander Graf
2026-08-09 18:20 ` [RFC PATCH 08/12] virtio_pci: support VIRTIO_F_DMB Alexander Graf
2026-08-09 22:14 ` Michael S. Tsirkin
2026-08-09 18:20 ` [RFC PATCH 09/12] Documentation: virtio: describe the device memory buffer Alexander Graf
2026-08-09 22:09 ` Michael S. Tsirkin
2026-08-09 18:20 ` [RFC PATCH 10/12] virtio_ring: report a bounded pool's exhaustion as -ENOSPC Alexander Graf
2026-08-09 18:20 ` [RFC PATCH 11/12] virtio: expose device memory buffer occupancy over debugfs Alexander Graf
2026-08-09 18:44 ` sashiko-bot
2026-08-09 18:20 ` [RFC PATCH 12/12] virtio: guarantee a virtqueue can publish its first descriptor chain Alexander Graf
2026-08-09 22:41 ` Michael S. Tsirkin
2026-08-09 23:15 ` Randy Dunlap
2026-08-10 6:23 ` [RFC PATCH 00/12] virtio: support devices that own their virtqueue memory Michael S. Tsirkin
2026-08-10 7:39 ` Graf (AWS), Alexander
2026-08-10 8:04 ` Michael S. Tsirkin
2026-08-10 8:25 ` Graf (AWS), Alexander
2026-08-10 19:14 ` Graf (AWS), Alexander
2026-08-10 21:42 ` Michael S. Tsirkin
2026-08-10 20:39 ` Stefan Hajnoczi
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=20260809184247-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=eperezma@redhat.com \
--cc=graf@amazon.com \
--cc=jasowangio@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nh-open-source@amazon.com \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/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.