All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Alistair Delva <adelva@google.com>,
	Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	virtualization@lists.linux-foundation.org,
	Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH net] virtio_net: CTRL_GUEST_OFFLOADS depends on CTRL_VQ
Date: Sun, 5 Jan 2020 06:16:30 -0500	[thread overview]
Message-ID: <20200105061532-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ea5131fc-cda6-c773-73fc-c862be6ecb7b@redhat.com>

On Tue, Dec 24, 2019 at 10:49:13AM +0800, Jason Wang wrote:
> 
> On 2019/12/24 上午4:21, Alistair Delva wrote:
> > On Mon, Dec 23, 2019 at 12:12 PM Willem de Bruijn
> > <willemdebruijn.kernel@gmail.com> wrote:
> > > On Mon, Dec 23, 2019 at 2:56 PM Willem de Bruijn
> > > <willemdebruijn.kernel@gmail.com> wrote:
> > > > 00fffe0ff0 DR7: 0000000000000400
> > > > > > Call Trace:
> > > > > >   ? preempt_count_add+0x58/0xb0
> > > > > >   ? _raw_spin_lock_irqsave+0x36/0x70
> > > > > >   ? _raw_spin_unlock_irqrestore+0x1a/0x40
> > > > > >   ? __wake_up+0x70/0x190
> > > > > >   virtnet_set_features+0x90/0xf0 [virtio_net]
> > > > > >   __netdev_update_features+0x271/0x980
> > > > > >   ? nlmsg_notify+0x5b/0xa0
> > > > > >   dev_disable_lro+0x2b/0x190
> > > > > >   ? inet_netconf_notify_devconf+0xe2/0x120
> > > > > >   devinet_sysctl_forward+0x176/0x1e0
> > > > > >   proc_sys_call_handler+0x1f0/0x250
> > > > > >   proc_sys_write+0xf/0x20
> > > > > >   __vfs_write+0x3e/0x190
> > > > > >   ? __sb_start_write+0x6d/0xd0
> > > > > >   vfs_write+0xd3/0x190
> > > > > >   ksys_write+0x68/0xd0
> > > > > >   __ia32_sys_write+0x14/0x20
> > > > > >   do_fast_syscall_32+0x86/0xe0
> > > > > >   entry_SYSENTER_compat+0x7c/0x8e
> > > > > > 
> > > > > > A similar crash will likely trigger when enabling XDP.
> > > > > > 
> > > > > > Reported-by: Alistair Delva <adelva@google.com>
> > > > > > Reported-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> > > > > > Fixes: 3f93522ffab2 ("virtio-net: switch off offloads on demand if possible on XDP set")
> > > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > > ---
> > > > > > 
> > > > > > Lightly tested.
> > > > > > 
> > > > > > Alistair, could you please test and confirm that this resolves the
> > > > > > crash for you?
> > > > > This patch doesn't work. The reason is that NETIF_F_LRO is also turned
> > > > > on by TSO4/TSO6, which your patch didn't check for. So it ends up
> > > > > going through the same path and crashing in the same way.
> > > > > 
> > > > >          if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
> > > > >              virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6))
> > > > >                  dev->features |= NETIF_F_LRO;
> > > > > 
> > > > > It sounds like this patch is fixing something slightly differently to
> > > > > my patch fixed. virtnet_set_features() doesn't care about
> > > > > GUEST_OFFLOADS, it only tests against NETIF_F_LRO. Even if "offloads"
> > > > > is zero, it will call virtnet_set_guest_offloads(), which triggers the
> > > > > crash.
> > > > 
> > > > Interesting. It's surprising that it is trying to configure a flag
> > > > that is not configurable, i.e., absent from dev->hw_features
> > > > after Michael's change.
> > > > 
> > > > > So either we need to ensure NETIF_F_LRO is never set, or
> > > > LRO might be available, just not configurable. Indeed this was what I
> > > > observed in the past.
> > > dev_disable_lro expects that NETIF_F_LRO is always configurable. Which
> > > I guess is a reasonable assumption, just not necessarily the case in
> > > virtio_net.
> > > 
> > > So I think we need both patches. Correctly mark the feature as fixed
> > > by removing from dev->hw_features and also ignore the request from
> > > dev_disable_lro, which does not check for this.
> > Something like this maybe:
> > 
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 4d7d5434cc5d..0556f42b0fb5 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -2560,6 +2560,9 @@ static int virtnet_set_features(struct net_device *dev,
> >          u64 offloads;
> >          int err;
> > 
> > +       if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS))
> > +               return 0;
> > +
> >          if ((dev->features ^ features) & NETIF_F_LRO) {
> >                  if (vi->xdp_queue_pairs)
> >                          return -EBUSY;
> > @@ -2971,6 +2974,15 @@ static int virtnet_validate(struct virtio_device *vdev)
> >          if (!virtnet_validate_features(vdev))
> >                  return -EINVAL;
> > 
> > +       /* VIRTIO_NET_F_CTRL_GUEST_OFFLOADS does not work without
> > +        * VIRTIO_NET_F_CTRL_VQ. However the virtio spec does not
> > +        * specify that VIRTIO_NET_F_CTRL_GUEST_OFFLOADS depends
> > +        * on VIRTIO_NET_F_CTRL_VQ so devices can set the later but
> > +        * not the former.
> > +        */
> > +       if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> > +               __virtio_clear_bit(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS);
> > +
> >          if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
> >                  int mtu = virtio_cread16(vdev,
> >                                           offsetof(struct virtio_net_config,
> > 
> 
> We check feature dependency and fail the probe in
> virtnet_validate_features().
> 
> Is it more straightforward to fail the probe there when CTRL_GUEST_OFFLOADS
> was set but CTRL_VQ wasn't?
> 
> Thanks

Expanding on what the comment above says, we can't fail probe
in this configuration without breaking the driver for
spec compliant devices.

-- 
MST


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Alistair Delva <adelva@google.com>,
	Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	Network Development <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net] virtio_net: CTRL_GUEST_OFFLOADS depends on CTRL_VQ
Date: Sun, 5 Jan 2020 06:16:30 -0500	[thread overview]
Message-ID: <20200105061532-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ea5131fc-cda6-c773-73fc-c862be6ecb7b@redhat.com>

On Tue, Dec 24, 2019 at 10:49:13AM +0800, Jason Wang wrote:
> 
> On 2019/12/24 上午4:21, Alistair Delva wrote:
> > On Mon, Dec 23, 2019 at 12:12 PM Willem de Bruijn
> > <willemdebruijn.kernel@gmail.com> wrote:
> > > On Mon, Dec 23, 2019 at 2:56 PM Willem de Bruijn
> > > <willemdebruijn.kernel@gmail.com> wrote:
> > > > 00fffe0ff0 DR7: 0000000000000400
> > > > > > Call Trace:
> > > > > >   ? preempt_count_add+0x58/0xb0
> > > > > >   ? _raw_spin_lock_irqsave+0x36/0x70
> > > > > >   ? _raw_spin_unlock_irqrestore+0x1a/0x40
> > > > > >   ? __wake_up+0x70/0x190
> > > > > >   virtnet_set_features+0x90/0xf0 [virtio_net]
> > > > > >   __netdev_update_features+0x271/0x980
> > > > > >   ? nlmsg_notify+0x5b/0xa0
> > > > > >   dev_disable_lro+0x2b/0x190
> > > > > >   ? inet_netconf_notify_devconf+0xe2/0x120
> > > > > >   devinet_sysctl_forward+0x176/0x1e0
> > > > > >   proc_sys_call_handler+0x1f0/0x250
> > > > > >   proc_sys_write+0xf/0x20
> > > > > >   __vfs_write+0x3e/0x190
> > > > > >   ? __sb_start_write+0x6d/0xd0
> > > > > >   vfs_write+0xd3/0x190
> > > > > >   ksys_write+0x68/0xd0
> > > > > >   __ia32_sys_write+0x14/0x20
> > > > > >   do_fast_syscall_32+0x86/0xe0
> > > > > >   entry_SYSENTER_compat+0x7c/0x8e
> > > > > > 
> > > > > > A similar crash will likely trigger when enabling XDP.
> > > > > > 
> > > > > > Reported-by: Alistair Delva <adelva@google.com>
> > > > > > Reported-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> > > > > > Fixes: 3f93522ffab2 ("virtio-net: switch off offloads on demand if possible on XDP set")
> > > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > > ---
> > > > > > 
> > > > > > Lightly tested.
> > > > > > 
> > > > > > Alistair, could you please test and confirm that this resolves the
> > > > > > crash for you?
> > > > > This patch doesn't work. The reason is that NETIF_F_LRO is also turned
> > > > > on by TSO4/TSO6, which your patch didn't check for. So it ends up
> > > > > going through the same path and crashing in the same way.
> > > > > 
> > > > >          if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
> > > > >              virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6))
> > > > >                  dev->features |= NETIF_F_LRO;
> > > > > 
> > > > > It sounds like this patch is fixing something slightly differently to
> > > > > my patch fixed. virtnet_set_features() doesn't care about
> > > > > GUEST_OFFLOADS, it only tests against NETIF_F_LRO. Even if "offloads"
> > > > > is zero, it will call virtnet_set_guest_offloads(), which triggers the
> > > > > crash.
> > > > 
> > > > Interesting. It's surprising that it is trying to configure a flag
> > > > that is not configurable, i.e., absent from dev->hw_features
> > > > after Michael's change.
> > > > 
> > > > > So either we need to ensure NETIF_F_LRO is never set, or
> > > > LRO might be available, just not configurable. Indeed this was what I
> > > > observed in the past.
> > > dev_disable_lro expects that NETIF_F_LRO is always configurable. Which
> > > I guess is a reasonable assumption, just not necessarily the case in
> > > virtio_net.
> > > 
> > > So I think we need both patches. Correctly mark the feature as fixed
> > > by removing from dev->hw_features and also ignore the request from
> > > dev_disable_lro, which does not check for this.
> > Something like this maybe:
> > 
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 4d7d5434cc5d..0556f42b0fb5 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -2560,6 +2560,9 @@ static int virtnet_set_features(struct net_device *dev,
> >          u64 offloads;
> >          int err;
> > 
> > +       if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS))
> > +               return 0;
> > +
> >          if ((dev->features ^ features) & NETIF_F_LRO) {
> >                  if (vi->xdp_queue_pairs)
> >                          return -EBUSY;
> > @@ -2971,6 +2974,15 @@ static int virtnet_validate(struct virtio_device *vdev)
> >          if (!virtnet_validate_features(vdev))
> >                  return -EINVAL;
> > 
> > +       /* VIRTIO_NET_F_CTRL_GUEST_OFFLOADS does not work without
> > +        * VIRTIO_NET_F_CTRL_VQ. However the virtio spec does not
> > +        * specify that VIRTIO_NET_F_CTRL_GUEST_OFFLOADS depends
> > +        * on VIRTIO_NET_F_CTRL_VQ so devices can set the later but
> > +        * not the former.
> > +        */
> > +       if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> > +               __virtio_clear_bit(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS);
> > +
> >          if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
> >                  int mtu = virtio_cread16(vdev,
> >                                           offsetof(struct virtio_net_config,
> > 
> 
> We check feature dependency and fail the probe in
> virtnet_validate_features().
> 
> Is it more straightforward to fail the probe there when CTRL_GUEST_OFFLOADS
> was set but CTRL_VQ wasn't?
> 
> Thanks

Expanding on what the comment above says, we can't fail probe
in this configuration without breaking the driver for
spec compliant devices.

-- 
MST

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2020-01-05 11:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-23 14:09 [PATCH net] virtio_net: CTRL_GUEST_OFFLOADS depends on CTRL_VQ Michael S. Tsirkin
2019-12-23 17:40 ` Alistair Delva
2019-12-23 19:44   ` Michael S. Tsirkin
2019-12-23 19:44   ` Michael S. Tsirkin
2019-12-23 19:56   ` Willem de Bruijn
2019-12-23 20:12     ` Willem de Bruijn
2019-12-23 20:12     ` Willem de Bruijn
2019-12-23 20:21       ` Alistair Delva
2019-12-24  2:49         ` Jason Wang
2020-01-05 11:16           ` Michael S. Tsirkin [this message]
2020-01-05 11:16             ` Michael S. Tsirkin
2019-12-24  2:49         ` Jason Wang
2019-12-25 16:02         ` Willem de Bruijn
2019-12-25 16:02         ` Willem de Bruijn
2019-12-26 19:12           ` Alistair Delva
2020-01-05 13:13         ` Michael S. Tsirkin
2020-01-05 13:13         ` Michael S. Tsirkin
2019-12-23 19:56   ` Willem de Bruijn
2019-12-23 14:09 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=20200105061532-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=adelva@google.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=willemdebruijn.kernel@gmail.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.