From: sashiko-bot@kernel.org
To: "Björn Töpel" <bjorn@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [RFC net-next 13/15] eth: fbnic: Support AF_XDP zero-copy receive
Date: Sat, 03 Oct 2026 19:02:40 +0000 [thread overview]
Message-ID: <20261003190241.90D191F0089B@smtp.kernel.org> (raw)
In-Reply-To: <20261002190018.696925-14-bjorn@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] net: deadlock on 32-bit during u64_stats_sync update with preemption enabled
--
commit 1bc54e591deb70184971cd19a4b1a9d18715cb4e
Author: Björn Töpel <bjorn@kernel.org>
eth: fbnic: Support AF_XDP zero-copy receive
This commit adds support for AF_XDP zero-copy receive in the fbnic driver.
It integrates the XSK buffer pool as a memory provider for page_pool and
refactors the receive ring refill loops to balance header and payload buffers.
> diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c b/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c
> --- a/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c
> +++ b/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c
[ ... ]
> -static void fbnic_fill_bdq(struct fbnic_ring *bdq)
> +static bool fbnic_fill_bdq_one(struct fbnic_ring *bdq, unsigned int *tail)
> {
> - unsigned int count = fbnic_desc_unused(bdq);
> - unsigned int i = bdq->tail;
> + netmem_ref netmem;
>
> - if (!count)
> - return;
> + netmem = page_pool_dev_alloc_netmems(bdq->page_pool);
> + if (!netmem) {
> + u64_stats_update_begin(&bdq->stats.syncp);
[Severity: High]
Does this code risk a deadlock on 32-bit systems when called from process
context with preemption enabled?
If memory allocation fails here during interface bring-up (e.g., via
ndo_open -> fbnic_up() -> fbnic_fill() -> fbnic_nv_fill() -> fbnic_fill_bdqs()
-> fbnic_fill_bdq_one()), the sequence counter is updated without disabling
preemption.
If the thread is preempted while the sequence counter is odd, and another
thread attempts to read network statistics (like ndo_get_stats64 or
get_queue_stats_rx), the reader will spin forever preventing the writer
from finishing, leading to a hard deadlock.
> + bdq->stats.bdq.alloc_failed++;
> + u64_stats_update_end(&bdq->stats.syncp);
> + return false;
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261002190018.696925-1-bjorn@kernel.org?part=13
next prev parent reply other threads:[~2026-10-03 19:02 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 19:00 [RFC net-next 00/15] xsk: Zero copy through page-pool memory providers Björn Töpel
2026-10-02 19:00 ` [RFC net-next 01/15] xdp: Size zero-copy skb heads by their contents Björn Töpel
2026-10-02 19:00 ` [RFC net-next 02/15] eth: fbnic: Report the logical XDP RX queue Björn Töpel
2026-10-02 19:00 ` [RFC net-next 03/15] net: Add memory provider capabilities Björn Töpel
2026-10-03 4:13 ` Mina Almasry
2026-10-09 14:54 ` Björn Töpel
2026-10-03 19:02 ` sashiko-bot
2026-10-12 18:54 ` Björn Töpel
2026-10-05 16:26 ` Stanislav Fomichev
2026-10-12 13:34 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 04/15] net: Let memory providers set RX buffer headroom Björn Töpel
2026-10-05 16:52 ` Stanislav Fomichev
2026-10-12 13:35 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 05/15] page_pool: Extend memory provider operations Björn Töpel
2026-10-05 16:51 ` Stanislav Fomichev
2026-10-12 13:53 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 06/15] xdp: Track non-page netmem in receive buffers Björn Töpel
2026-10-05 17:01 ` Stanislav Fomichev
2026-10-12 14:12 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 07/15] xsk: Keep the DMA mapping in the buffer pool Björn Töpel
2026-10-02 19:00 ` [RFC net-next 08/15] xsk: Handle a detached FILL ring in RX wakeup Björn Töpel
2026-10-02 19:00 ` [RFC net-next 09/15] xsk: Add a page-pool memory provider for UMEM Björn Töpel
2026-10-05 17:38 ` Stanislav Fomichev
2026-10-12 14:14 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 10/15] xsk: Add RX helpers for page-pool drivers Björn Töpel
2026-10-02 19:00 ` [RFC net-next 11/15] xdp: Copy provider buffers on pass and redirect Björn Töpel
2026-10-03 19:02 ` sashiko-bot
2026-10-12 18:55 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 12/15] xsk: Receive provider UMEM without copying Björn Töpel
2026-10-02 19:00 ` [RFC net-next 13/15] eth: fbnic: Support AF_XDP zero-copy receive Björn Töpel
2026-10-03 19:02 ` sashiko-bot [this message]
2026-10-12 18:56 ` Björn Töpel
2026-10-05 17:51 ` Stanislav Fomichev
2026-10-12 14:16 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 14/15] eth: fbnic: Support AF_XDP zero-copy transmit Björn Töpel
2026-10-02 19:00 ` [RFC net-next 15/15] Documentation: xsk: Document page-pool zero copy Björn Töpel
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=20261003190241.90D191F0089B@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.