| Message ID | b90034c61b939d18cd7a201c547fb7ddffc91231.1668727939.git.pabeni@redhat.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | veth: a couple of fixes | expand |
> While investigating a related issue I stumbled upon another > oops, reproducible as the follow: > > ip link add type veth > ip link set dev veth0 xdp object <obj> > ip link set dev veth0 up > ip link set dev veth1 up > > The first link up command will enable the napi instances on > veth1 and the second link up common will try again the same > operation, causing the oops. > > This change addresses the issue explicitly checking the peer > is up before enabling its napi instances. > > Fixes: 2e0de6366ac1 ("veth: Avoid drop packets when xdp_redirect performs") > Signed-off-by: Paolo Abeni <pabeni@redhat.com> > --- > drivers/net/veth.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/veth.c b/drivers/net/veth.c > index 1384134f7100..d541183e0c66 100644 > --- a/drivers/net/veth.c > +++ b/drivers/net/veth.c > @@ -1343,7 +1343,8 @@ static int veth_open(struct net_device *dev) > if (err) > return err; > /* refer to the logic in veth_xdp_set() */ > - if (!rtnl_dereference(peer_rq->napi)) { > + if (!rtnl_dereference(peer_rq->napi) && > + (peer->flags & IFF_UP)) { > err = veth_napi_enable(peer); > if (err) > return err; I have checked the conditions related to enabling and disabling napi for veth pair. In general, we should check whether napi is disabled before enabling it, and check whether napi is enabled before disabling it. I am sorry that my previous test cases didn't do better, and we can work completely with your patchset. As the your patch in link below does https://lore.kernel.org/all/c59f4adcdd1296ee37cc6bca4d927b8c79158909.1668727939.git.pabeni@redhat.com/ Is this patch more uniform like the following: --- a/drivers/net/veth.c +++ b/drivers/net/veth.c @@ -1348,7 +1348,8 @@ static int veth_open(struct net_device *dev) if (err) return err; } - } else if (veth_gro_requested(dev) || peer_priv->_xdp_prog) { + } else if ((veth_gro_requested(dev) || peer_priv->_xdp_prog) && + !rtnl_dereference(priv->rq[0].napi)) { err = veth_napi_enable(dev); if (err) return err; Thanks.
diff --git a/drivers/net/veth.c b/drivers/net/veth.c index 1384134f7100..d541183e0c66 100644 --- a/drivers/net/veth.c +++ b/drivers/net/veth.c @@ -1343,7 +1343,8 @@ static int veth_open(struct net_device *dev) if (err) return err; /* refer to the logic in veth_xdp_set() */ - if (!rtnl_dereference(peer_rq->napi)) { + if (!rtnl_dereference(peer_rq->napi) && + (peer->flags & IFF_UP)) { err = veth_napi_enable(peer); if (err) return err;
While investigating a related issue I stumbled upon another oops, reproducible as the follow: ip link add type veth ip link set dev veth0 xdp object <obj> ip link set dev veth0 up ip link set dev veth1 up The first link up command will enable the napi instances on veth1 and the second link up common will try again the same operation, causing the oops. This change addresses the issue explicitly checking the peer is up before enabling its napi instances. Fixes: 2e0de6366ac1 ("veth: Avoid drop packets when xdp_redirect performs") Signed-off-by: Paolo Abeni <pabeni@redhat.com> --- drivers/net/veth.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)