From: "Michael S. Tsirkin" <mst@redhat.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>,
"David S. Miller" <davem@davemloft.net>,
stable@vger.kernel.org,
virtualization@lists.linux-foundation.org
Subject: Re: Merge of "virtio_net: fix race in RX VQ processing" for linux-3.2.48
Date: Sun, 28 Jul 2013 10:11:56 +0300 [thread overview]
Message-ID: <20130728071156.GD12087@redhat.com> (raw)
In-Reply-To: <1374936173.13555.19.camel@deadeye.wl.decadent.org.uk>
On Sat, Jul 27, 2013 at 03:42:53PM +0100, Ben Hutchings wrote:
> On Fri, 2013-07-12 at 23:13 +0200, Wolfram Gloger wrote:
> > Hi,
> >
> > Today I merged M. Tsirkin's patch v2 "virtio_net: fix race in RX VQ
> > processing":
> >
> > http://lkml.indiana.edu/hypermail/linux/kernel/1307.1/00503.html
> >
> > into 3.2.48 and lightly tested the result (vhost-net, virtio-disk
> > and 9pfs using virtio).
>
> This sounds like it could be suitable for stable, but that doesn't seem
> to have been requested by the author.
It was in the cover letter:
"Please review, and consider for 3.11 and stable."
> I'm cc'ing those involved so they
> can make a decision whether this should be included in 3.2.y or other
> stable branches.
> > Merge is not completely trivial, so might save you some time, if only
> > for a comparison that you arrive at the same result.
>
> Thanks, but these are not in quite the right patch format. The
> filenames should always have a leading directory name which will be
> stripped (patch -p1). The original patch header must be preserved and a
> reference to the upstream commit inserted e.g.
> 'commit 0123456789abcdef0123456789abcdef012345678 upstream.'
>
> (Attachments copied for reference.)
>
> Ben.
>
> --
> Ben Hutchings
> Once a job is fouled up, anything done to improve it makes it worse.
>
> --- drivers/virtio/virtio_ring.c.orig 2013-06-30 11:35:44.000000000 +0200
> +++ drivers/virtio/virtio_ring.c 2013-07-12 15:18:48.000000000 +0200
> @@ -360,9 +360,22 @@ void virtqueue_disable_cb(struct virtque
> }
> EXPORT_SYMBOL_GPL(virtqueue_disable_cb);
>
> -bool virtqueue_enable_cb(struct virtqueue *_vq)
> +/**
> + * virtqueue_enable_cb_prepare - restart callbacks after disable_cb
> + * @vq: the struct virtqueue we're talking about.
> + *
> + * This re-enables callbacks; it returns current queue state
> + * in an opaque unsigned value. This value should be later tested by
> + * virtqueue_poll, to detect a possible race between the driver checking for
> + * more work, and enabling callbacks.
> + *
> + * Caller must ensure we don't call this with other virtqueue
> + * operations at the same time (except where noted).
> + */
> +unsigned virtqueue_enable_cb_prepare(struct virtqueue *_vq)
> {
> struct vring_virtqueue *vq = to_vvq(_vq);
> + u16 last_used_idx;
>
> START_USE(vq);
>
> @@ -372,15 +385,45 @@ bool virtqueue_enable_cb(struct virtqueu
> * either clear the flags bit or point the event index at the next
> * entry. Always do both to keep code simple. */
> vq->vring.avail->flags &= ~VRING_AVAIL_F_NO_INTERRUPT;
> - vring_used_event(&vq->vring) = vq->last_used_idx;
> + vring_used_event(&vq->vring) = last_used_idx = vq->last_used_idx;
> + END_USE(vq);
> + return last_used_idx;
> +}
> +EXPORT_SYMBOL_GPL(virtqueue_enable_cb_prepare);
> +
> +/**
> + * virtqueue_poll - query pending used buffers
> + * @vq: the struct virtqueue we're talking about.
> + * @last_used_idx: virtqueue state (from call to virtqueue_enable_cb_prepare).
> + *
> + * Returns "true" if there are pending used buffers in the queue.
> + *
> + * This does not need to be serialized.
> + */
> +bool virtqueue_poll(struct virtqueue *_vq, unsigned last_used_idx)
> +{
> + struct vring_virtqueue *vq = to_vvq(_vq);
> +
> virtio_mb();
> - if (unlikely(more_used(vq))) {
> - END_USE(vq);
> - return false;
> - }
> + return (u16)last_used_idx != vq->vring.used->idx;
> +}
> +EXPORT_SYMBOL_GPL(virtqueue_poll);
>
> - END_USE(vq);
> - return true;
> +/**
> + * virtqueue_enable_cb - restart callbacks after disable_cb.
> + * @vq: the struct virtqueue we're talking about.
> + *
> + * This re-enables callbacks; it returns "false" if there are pending
> + * buffers in the queue, to detect a possible race between the driver
> + * checking for more work, and enabling callbacks.
> + *
> + * Caller must ensure we don't call this with other virtqueue
> + * operations at the same time (except where noted).
> + */
> +bool virtqueue_enable_cb(struct virtqueue *_vq)
> +{
> + unsigned last_used_idx = virtqueue_enable_cb_prepare(_vq);
> + return !virtqueue_poll(_vq, last_used_idx);
> }
> EXPORT_SYMBOL_GPL(virtqueue_enable_cb);
>
> --- include/linux/virtio.h.orig 2012-01-05 00:55:44.000000000 +0100
> +++ include/linux/virtio.h 2013-07-12 14:42:26.000000000 +0200
> @@ -96,6 +96,10 @@ void virtqueue_disable_cb(struct virtque
>
> bool virtqueue_enable_cb(struct virtqueue *vq);
>
> +unsigned virtqueue_enable_cb_prepare(struct virtqueue *vq);
> +
> +bool virtqueue_poll(struct virtqueue *vq, unsigned);
> +
> bool virtqueue_enable_cb_delayed(struct virtqueue *vq);
>
> void *virtqueue_detach_unused_buf(struct virtqueue *vq);
> --- drivers/net/virtio_net.c.orig 2012-01-05 00:55:44.000000000 +0100
> +++ drivers/net/virtio_net.c 2013-07-12 15:39:06.000000000 +0200
> @@ -508,7 +508,7 @@ static int virtnet_poll(struct napi_stru
> {
> struct virtnet_info *vi = container_of(napi, struct virtnet_info, napi);
> void *buf;
> - unsigned int len, received = 0;
> + unsigned int r, len, received = 0;
>
> again:
> while (received < budget &&
> @@ -525,8 +525,9 @@ again:
>
> /* Out of packets? */
> if (received < budget) {
> + r = virtqueue_enable_cb_prepare(vi->rvq);
> napi_complete(napi);
> - if (unlikely(!virtqueue_enable_cb(vi->rvq)) &&
> + if (unlikely(virtqueue_poll(vi->rvq, r)) &&
> napi_schedule_prep(napi)) {
> virtqueue_disable_cb(vi->rvq);
> __napi_schedule(napi);
prev parent reply other threads:[~2013-07-28 7:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <u4ehb37a8w.fsf@md.dent.med.uni-muenchen.de>
2013-07-27 14:42 ` Merge of "virtio_net: fix race in RX VQ processing" for linux-3.2.48 Ben Hutchings
2013-07-28 7:11 ` Michael S. Tsirkin [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=20130728071156.GD12087@redhat.com \
--to=mst@redhat.com \
--cc=ben@decadent.org.uk \
--cc=davem@davemloft.net \
--cc=stable@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=wmglo@dent.med.uni-muenchen.de \
/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;
as well as URLs for NNTP newsgroup(s).