From: Heng Qi <hengqi@linux.alibaba.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: netdev@vger.kernel.org, virtualization@lists.linux.dev,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Jiri Pirko" <jiri@resnulli.us>,
"Daniel Jurgens" <danielj@nvidia.com>
Subject: Re: [PATCH net 2/2] virtio_net: fix missing lock protection on control_buf access
Date: Wed, 29 May 2024 10:02:18 +0800 [thread overview]
Message-ID: <1716948138.442408-2-hengqi@linux.alibaba.com> (raw)
In-Reply-To: <20240528124435-mutt-send-email-mst@kernel.org>
On Tue, 28 May 2024 12:45:32 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, May 29, 2024 at 12:01:45AM +0800, Heng Qi wrote:
> > On Tue, 28 May 2024 11:46:28 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On Tue, May 28, 2024 at 03:52:26PM +0800, Heng Qi wrote:
> > > > Refactored the handling of control_buf to be within the cvq_lock
> > > > critical section, mitigating race conditions between reading device
> > > > responses and new command submissions.
> > > >
> > > > Fixes: 6f45ab3e0409 ("virtio_net: Add a lock for the command VQ.")
> > > > Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > >
> > >
> > > I don't get what does this change. status can change immediately
> > > after you drop the mutex, can it not? what exactly is the
> > > race conditions you are worried about?
> >
> > See the following case:
> >
> > 1. Command A is acknowledged and successfully executed by the device.
> > 2. After releasing the mutex (mutex_unlock), process P1 gets preempted before
> > it can read vi->ctrl->status, *which should be VIRTIO_NET_OK*.
> > 3. A new command B (like the DIM command) is issued.
> > 4. Post vi->ctrl->status being set to VIRTIO_NET_ERR by
> > virtnet_send_command_reply(), process P2 gets preempted.
> > 5. Process P1 resumes, reads *vi->ctrl->status as VIRTIO_NET_ERR*, and reports
> > this error back for Command A. <-- Race causes incorrect results to be read.
> >
> > Thanks.
>
>
> Why is it important that P1 gets VIRTIO_NET_OK?
> After all it is no longer the state.
The driver needs to know whether the command actually executed success.
Thanks.
>
> > >
> > > > ---
> > > > drivers/net/virtio_net.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > index 6b0512a628e0..3d8407d9e3d2 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -2686,6 +2686,7 @@ static bool virtnet_send_command_reply(struct virtnet_info *vi, u8 class, u8 cmd
> > > > {
> > > > struct scatterlist *sgs[5], hdr, stat;
> > > > u32 out_num = 0, tmp, in_num = 0;
> > > > + bool ret;
> > > > int err;
> > > >
> > > > /* Caller should know better */
> > > > @@ -2731,8 +2732,9 @@ static bool virtnet_send_command_reply(struct virtnet_info *vi, u8 class, u8 cmd
> > > > }
> > > >
> > > > unlock:
> > > > + ret = vi->ctrl->status == VIRTIO_NET_OK;
> > > > mutex_unlock(&vi->cvq_lock);
> > > > - return vi->ctrl->status == VIRTIO_NET_OK;
> > > > + return ret;
> > > > }
> > > >
> > > > static bool virtnet_send_command(struct virtnet_info *vi, u8 class, u8 cmd,
> > > > --
> > > > 2.32.0.3.g01195cf9f
> > >
>
next prev parent reply other threads:[~2024-05-29 2:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 7:52 [PATCH net 0/2] virtio_net: fix race on control_buf Heng Qi
2024-05-28 7:52 ` [PATCH net 1/2] virtio_net: rename ret to err Heng Qi
2024-05-28 8:31 ` Hariprasad Kelam
2024-05-30 0:10 ` Jakub Kicinski
2024-05-30 3:10 ` Heng Qi
2024-05-28 7:52 ` [PATCH net 2/2] virtio_net: fix missing lock protection on control_buf access Heng Qi
2024-05-28 8:32 ` Hariprasad Kelam
2024-05-28 15:46 ` Michael S. Tsirkin
2024-05-28 16:01 ` Heng Qi
2024-05-28 16:45 ` Michael S. Tsirkin
2024-05-29 2:02 ` Heng Qi [this message]
2024-06-23 10:06 ` [PATCH net 0/2] virtio_net: fix race on control_buf 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=1716948138.442408-2-hengqi@linux.alibaba.com \
--to=hengqi@linux.alibaba.com \
--cc=danielj@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@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.