From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexander Graf <graf@amazon.com>
Cc: "Johannes Thumshirn" <Johannes.Thumshirn@wdc.com>,
"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] virtio: silence KCSAN warning in virtqueue_get_buf_ctx_split
Date: Wed, 28 Jan 2026 05:34:39 -0500 [thread overview]
Message-ID: <20260128053356-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <87ee6ad5-7c58-4e40-92fe-57305ce2b00a@amazon.com>
On Wed, Jan 28, 2026 at 11:30:20AM +0100, Alexander Graf wrote:
>
> On 28.01.26 10:13, Johannes Thumshirn wrote:
> > On 1/28/26 10:03 AM, Alexander Graf wrote:
> > > On 28.01.26 09:47, Johannes Thumshirn wrote:
> > > > On 1/27/26 5:30 PM, Alexander Graf wrote:
> > > > > This patches the split vring format, but does not touch the packed one.
> > > > > What happens if you run the same test with the packed format? You can do
> > > > > so by passing "packed=on" as argument to your -device parameter.
> > > > This opened up a whole new can of worms... :(
> > > That's what I expected :).
> > >
> > > How do other DMA based devices handle this? Is the real problem that
> > > virtio by default does not use the DMA API and so it confuses generic
> > > KCSAN logic that would otherwise track DMA regions as "can be modified
> > > by DMA at any time"?
> > >
> > > If that is the case, maybe what we really want is to force enable use of
> > > the DMA API when KCSAN is active. Does something like the (whitespace
> > > broken) patch below work?
> > >
> > > Alex
> > >
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > index ddab68959671..b1dd790ce622 100644
> > > --- a/drivers/virtio/virtio_ring.c
> > > +++ b/drivers/virtio/virtio_ring.c
> > > @@ -284,6 +284,13 @@ static bool vring_use_map_api(const struct
> > > virtio_device *vdev)
> > > if (xen_domain())
> > > return true;
> > >
> > > + /*
> > > + * KCSAN needs to track who can modify memory. DMA API gets
> > > + * us that, so always use it.
> > > + */
> > > + if (IS_ENABLED(CONFIG_KCSAN))
> > > + return true;
> > > +
> > > return false;
> > > }
> >
> > Unfortunately this doesn't get us any further (I'd love though, it looks
> > way cleaner!)
> >
> > I still see the KCSAN messages even on boot.
>
>
> Ah, looks like the important bit for KCSAN is not the mapping mechanism,
> it's the actual compiler annotation for the read. So these virtio ring reads
> should all be annotated as READ_ONCE() to make sure KCSAN knows the read
> itself is atomic.
>
> Alex
>
so then:
return vq->last_used_idx != virtio16_to_cpu(vq->vq.vdev,
READ_ONCE(vq->split.vring.used->idx));
?
>
>
> Amazon Web Services Development Center Germany GmbH
> Tamara-Danz-Str. 13
> 10243 Berlin
> Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> Sitz: Berlin
> Ust-ID: DE 365 538 597
next prev parent reply other threads:[~2026-01-28 10:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 15:25 [PATCH v2 0/2] virtio: silence KCSAN warnings Johannes Thumshirn
2026-01-27 15:25 ` [PATCH v2 1/2] virtio: silence KCSAN warning in virtqueue_get_buf_ctx_split Johannes Thumshirn
2026-01-27 16:30 ` Alexander Graf
2026-01-28 8:47 ` Johannes Thumshirn
2026-01-28 9:03 ` Alexander Graf
2026-01-28 9:13 ` Johannes Thumshirn
2026-01-28 10:30 ` Alexander Graf
2026-01-28 10:34 ` Michael S. Tsirkin [this message]
2026-01-28 10:38 ` Alexander Graf
2026-01-28 10:48 ` Michael S. Tsirkin
2026-01-27 15:25 ` [PATCH v2 2/2] virtio: silence KCSAN warning in virtqueue_kick_prepare Johannes Thumshirn
2026-01-28 12:28 ` kernel test robot
2026-01-28 22:23 ` kernel test robot
2026-01-27 15:44 ` [PATCH v2 0/2] virtio: silence KCSAN warnings Michael S. Tsirkin
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=20260128053356-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=eperezma@redhat.com \
--cc=graf@amazon.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox