On Thu, 12 Sept 2024 at 17:02, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
>
> Setting event_triggered from the interrupt handler
> is fundamentally racy. There are races of 2 types:
> 1. vq processing can read false value while interrupt
> triggered and set it to true.
> result will be a bit of extra work when disabling cbs, no big deal.
>
> 1. vq processing can set false value then interrupt
> immediately sets true value
> since interrupt then triggers a callback which will
> process buffers, this is also not an issue.
>
> However, looks like KCSAN can not figure all this out, and warns about
> the race between the write and the read. Tag the access data_racy for
> now. We should probably look at ways to make this more
> straight-forwardly correct.
>
> Cc: Marco Elver <elver@xxxxxxxxxx>
> Reported-by: syzbot+8a02104389c2e0ef5049@xxxxxxxxxxxxxxxxxxxxxxxxx
> Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
Probably more conservative than the __data_racy hammer:
Acked-by: Marco Elver <elver@xxxxxxxxxx>
> ---
> drivers/virtio/virtio_ring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index be7309b1e860..98374ed7c577 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -2588,7 +2588,7 @@ irqreturn_t vring_interrupt(int irq, void *_vq)
>
> /* Just a hint for performance: so it's ok that this can be racy! */
> if (vq->event)
> - vq->event_triggered = true;
> + data_race(vq->event_triggered = true);
>
> pr_debug("virtqueue callback for %p (%p)\n", vq, vq->vq.callback);
> if (vq->vq.callback)
> --
> MST
>
