From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Praveen Kaligineedi <pkaligineedi@google.com>
Cc: <netdev@vger.kernel.org>, <jeroendb@google.com>,
<shailend@google.com>, <willemb@google.com>,
<andrew+netdev@lunn.ch>, <davem@davemloft.net>,
<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
<ast@kernel.org>, <daniel@iogearbox.net>, <hawk@kernel.org>,
<john.fastabend@gmail.com>, <horms@kernel.org>,
<hramamurthy@google.com>, <joshwash@google.com>,
<ziweixiao@google.com>, <linux-kernel@vger.kernel.org>,
<bpf@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH net 2/5] gve: guard XDP xmit NDO on existence of xdp queues
Date: Wed, 18 Dec 2024 16:30:49 +0100 [thread overview]
Message-ID: <3ad7bdd2-80d2-4d73-b86f-4c0aeeee5bf1@intel.com> (raw)
In-Reply-To: <20241218133415.3759501-3-pkaligineedi@google.com>
From: Praveen Kaligineedi <pkaligineedi@google.com>
Date: Wed, 18 Dec 2024 05:34:12 -0800
> From: Joshua Washington <joshwash@google.com>
>
> In GVE, dedicated XDP queues only exist when an XDP program is installed
> and the interface is up. As such, the NDO XDP XMIT callback should
> return early if either of these conditions are false.
>
> In the case of no loaded XDP program, priv->num_xdp_queues=0 which can
> cause a divide-by-zero error, and in the case of interface down,
> num_xdp_queues remains untouched to persist XDP queue count for the next
> interface up, but the TX pointer itself would be NULL.
>
> The XDP xmit callback also needs to synchronize with a device
> transitioning from open to close. This synchronization will happen via
> the GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,
> which waits for any RCU critical sections at call-time to complete.
>
> Fixes: 39a7f4aa3e4a ("gve: Add XDP REDIRECT support for GQI-QPL format")
> Cc: stable@vger.kernel.org
> Signed-off-by: Joshua Washington <joshwash@google.com>
> Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com>
> Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
> Reviewed-by: Shailend Chand <shailend@google.com>
> Reviewed-by: Willem de Bruijn <willemb@google.com>
> ---
> drivers/net/ethernet/google/gve/gve_main.c | 3 +++
> drivers/net/ethernet/google/gve/gve_tx.c | 5 ++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
> index e171ca248f9a..5d7b0cc59959 100644
> --- a/drivers/net/ethernet/google/gve/gve_main.c
> +++ b/drivers/net/ethernet/google/gve/gve_main.c
> @@ -1899,6 +1899,9 @@ static void gve_turndown(struct gve_priv *priv)
>
> gve_clear_napi_enabled(priv);
> gve_clear_report_stats(priv);
> +
> + /* Make sure that all traffic is finished processing. */
> + synchronize_net();
Wouldn't synchronize_rcu() be enough, have you checked?
> }
>
> static void gve_turnup(struct gve_priv *priv)
> diff --git a/drivers/net/ethernet/google/gve/gve_tx.c b/drivers/net/ethernet/google/gve/gve_tx.c
> index 83ad278ec91f..852f8c7e39d2 100644
> --- a/drivers/net/ethernet/google/gve/gve_tx.c
> +++ b/drivers/net/ethernet/google/gve/gve_tx.c
> @@ -837,9 +837,12 @@ int gve_xdp_xmit(struct net_device *dev, int n, struct xdp_frame **frames,
> struct gve_tx_ring *tx;
> int i, err = 0, qid;
>
> - if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
> + if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK) || !priv->xdp_prog)
> return -EINVAL;
The first condition (weird xmit flags) is certainly EINVAL.
Lack of installed XDP prog is *not*.
You need to use xdp_features_{set,clear}_redirect_target() when you
install/remove XDP prog to notify the kernel that ndo_start_xmit is now
available / not available anymore.
If you want to leave this check, I'd suggest changing it to
if (unlikely(!priv->num_xdp_queues))
return -ENXIO;
if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
return -EINVAL;
>
> + if (!gve_get_napi_enabled(priv))
> + return -ENETDOWN;
> +
> qid = gve_xdp_tx_queue_id(priv,
> smp_processor_id() % priv->num_xdp_queues);
Thanks,
Olek
next prev parent reply other threads:[~2024-12-18 15:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 13:34 [PATCH net 0/5] gve: various XDP fixes Praveen Kaligineedi
2024-12-18 13:34 ` [PATCH net 1/5] gve: clean XDP queues in gve_tx_stop_ring_gqi Praveen Kaligineedi
2024-12-18 13:34 ` [PATCH net 2/5] gve: guard XDP xmit NDO on existence of xdp queues Praveen Kaligineedi
2024-12-18 15:30 ` Alexander Lobakin [this message]
2025-01-02 18:43 ` Joshua Washington
2024-12-18 13:34 ` [PATCH net 3/5] gve: guard XSK operations on the existence of queues Praveen Kaligineedi
2024-12-19 17:34 ` Larysa Zaremba
2024-12-18 13:34 ` [PATCH net 4/5] gve: process XSK TX descriptors as part of RX NAPI Praveen Kaligineedi
2024-12-18 13:34 ` [PATCH net 5/5] gve: fix XDP allocation path in edge cases Praveen Kaligineedi
2024-12-20 13:00 ` [PATCH net 0/5] gve: various XDP fixes patchwork-bot+netdevbpf
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=3ad7bdd2-80d2-4d73-b86f-4c0aeeee5bf1@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=hramamurthy@google.com \
--cc=jeroendb@google.com \
--cc=john.fastabend@gmail.com \
--cc=joshwash@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pkaligineedi@google.com \
--cc=shailend@google.com \
--cc=stable@vger.kernel.org \
--cc=willemb@google.com \
--cc=ziweixiao@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox