RE: [PATCH net] virtio-net: clear NETIF_F_GRO_HW if no GRO-related offloads are capable

[Zhud <zhud@hygon.cn>]

> On Fri, Mar 13, 2026 at 9:37 AM Di Zhu <zhud@hygon.cn> wrote:
> >
> > Although VIRTIO_NET_F_CTRL_GUEST_OFFLOADS is negotiated, which
> > indicates the device supports dynamic control of guest offloads, it
> > does not necessarily mean the device supports specific hardware GRO features.
> >
> > If none of the features defined in GUEST_OFFLOAD_GRO_HW_MASK (such as
> > TSO4, TSO6, or UFO) are present in vi->guest_offloads_capable, the
> > device effectively lacks the hardware capability to perform GRO.
> >
> > In this case, NETIF_F_GRO_HW should be cleared from dev->hw_features
> > to prevent the stack from attempting to enable an unsupported hardware
> > offload configuration.
> >
> > Fixes: a02e8964eaf9 ("virtio-net: ethtool configurable LRO")
> > Signed-off-by: Di Zhu <zhud@hygon.cn>
> > ---
> >  drivers/net/virtio_net.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index
> > 72d6a9c6a5a2..49a60af684d5 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -7058,6 +7058,9 @@ static int virtnet_probe(struct virtio_device *vdev)
> >         }
> >         vi->guest_offloads_capable = vi->guest_offloads;
> >
> > +       if (!(vi->guest_offloads_capable & GUEST_OFFLOAD_GRO_HW_MASK))
> > +               dev->hw_features &= ~NETIF_F_GRO_HW;
> > +
> 
> It looks to me the root cause is this during probe?
> 
>         if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS))
>                 dev->hw_features |= NETIF_F_GRO_HW;
> 
> Thanks

	Exactly. It seems the code blindly enables NETIF_F_GRO_HW as long as the 
control channel is present, without verifying if the backend actually supports the
offload features.

> 
> >         rtnl_unlock();
> >
> >         err = virtnet_cpu_notif_add(vi);
> > --
> > 2.34.1
> >
> >
>