From: Simon Horman <horms@kernel.org>
To: Vaibhav Nagare <vnagare@redhat.com>
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@google.com, michael.chan@broadcom.com,
pavan.chebbi@broadcom.com, ast@kernel.org, daniel@iogearbox.net,
hawk@kernel.org, john.fastabend@gmail.com, sdf@fomichev.me,
andrew+netdev@lunn.ch, netdev@vger.kernel.org,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
nagarevaibhav@gmail.com, stable@vger.kernel.org
Subject: Re: [PATCH net v4] bnxt_en: don't leave an XDP program installed when the open fails
Date: Sun, 18 Oct 2026 15:01:20 +0100 [thread overview]
Message-ID: <20261018140120.GJ503057@horms.kernel.org> (raw)
In-Reply-To: <20261012072802.2153706-1-vnagare@redhat.com>
On Mon, Oct 12, 2026 at 12:58:02PM +0530, Vaibhav Nagare wrote:
> bnxt_xdp_set() stores the new program and drops the reference on the old
> one before reopening the NIC. If bnxt_open_nic() then fails, ndo_bpf()
> returns an error with the new program still in bp->xdp_prog. The caller
> treats the error as "nothing was installed" and drops its own reference,
> so bp->xdp_prog is left pointing at a freed program and the next XDP
> update dereferences it:
>
> BUG: unable to handle page fault for address: ff78ecc80ddd1038
> RIP: 0010:__bpf_prog_put+0x5/0x80
> Call Trace:
> bnxt_xdp_set+0xad/0x1b0 [bnxt_en]
> dev_xdp_propagate+0x36/0xa0
> bond_xdp_set+0xeb/0x2d0 [bonding]
> dev_xdp_install+0x1b1/0x350
> bpf_xdp_link_update+0xc5/0x1b0
> link_update+0x104/0x1e0
> __sys_bpf+0x662/0xcf0
>
> Seen on a 6.12 based kernel after bnxt_alloc_mem() failed an order-4
> allocation on a fragmented host:
>
> bnxt_en 0000:a0:00.1 ens4f1np1: nic open fail (rc: fffffff4)
> bond1: (slave ens4f1np1): Error -12 calling ndo_bpf
>
> Bonding is not required to hit this; a plain XDP attach on a bnxt
> interface takes the same path.
>
> Restore the previous program when an attach or a replace fails, and
> recompute the page-mode and XDP TX ring configuration from it. The
> configuration matters because bnxt_init_one_rx_ring() only assigns
> rxr->xdp_prog in page mode, and __bnxt_set_rx_skb_mode() derives
> dev->max_mtu from the installed program. Release the old program only
> once the change has been committed.
>
> A detach is not undone. dev_xdp_detach_link() clears the core's record
> of the program even when the driver returns an error, so putting the
> program back would leave the driver running a program the core has
> already dropped. If the reopen fails during a detach, bnxt_xdp_set()
> therefore returns 0 with the device closed; bnxt_open_nic() has already
> logged the failure.
>
> Found in a crash dump; the change was not tested on hardware.
>
> Fixes: c6d30e8391b8 ("bnxt_en: Add basic XDP support.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Vaibhav Nagare <vnagare@redhat.com>
> ---
> v4:
> - no functional change. Correct the comment and commit message: the
> core clears its record of the program on a failed detach, it does
> not drop a reference itself, and note that a failed reopen during a
> detach returns 0 with the device closed (Sashiko AI review)
> - the same review notes the rollback does not restore the RX
> aggregation-ring mode. That is real but pre-existing: without this
> patch the failed attach leaves the same bp->flags behind and the
> next open fails the same way. Restoring it needs a snapshot of
> bp->flags, the LRO/GRO_HW feature bits and the ring parameters,
> which is a separate change for net-next
> - v3: https://lore.kernel.org/netdev/20261001142516.1386525-1-vnagare@redhat.com/
> - v2: https://lore.kernel.org/netdev/20260930070901.1218980-1-vnagare@redhat.com/
> - v1: https://lore.kernel.org/netdev/20260928131458.1012180-1-vnagare@redhat.com/
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2026-10-18 14:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 7:28 [PATCH net v4] bnxt_en: don't leave an XDP program installed when the open fails Vaibhav Nagare
2026-10-18 14:01 ` Simon Horman [this message]
2026-10-19 13:20 ` 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=20261018140120.GJ503057@horms.kernel.org \
--to=horms@kernel.org \
--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=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.chan@broadcom.com \
--cc=nagarevaibhav@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=sdf@fomichev.me \
--cc=stable@vger.kernel.org \
--cc=vnagare@redhat.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