public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: "Tantilov, Emil S" <emil.s.tantilov@intel.com>
Cc: daniel@iogearbox.net, ast@kernel.org, willemb@google.com,
	stable@vger.kernel.org, decot@google.com, bpf@vger.kernel.org,
	anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
	intel-wired-lan@lists.osuosl.org, edumazet@google.com,
	netdev@vger.kernel.org, pabeni@redhat.com, andrew+netdev@lunn.ch,
	kuba@kernel.org, davem@davemloft.net, sdf@fomichev.me,
	aleksandr.loktionov@intel.com, aleksander.lobakin@intel.com,
	john.fastabend@gmail.com, hawk@kernel.org
Subject: Re: [PATCH iwl-net v2] idpf: fix xdp crash in soft reset error path
Date: Sat, 21 Mar 2026 09:17:53 +0000	[thread overview]
Message-ID: <20260321091753.GT74886@horms.kernel.org> (raw)
In-Reply-To: <0275cffc-7a61-46fb-9d1e-c309ac680b80@intel.com>

On Fri, Mar 20, 2026 at 02:35:42PM -0700, Tantilov, Emil S wrote:
> 
> 
> On 3/20/2026 10:48 AM, Simon Horman wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > 
> > For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> > ---
> > idpf: fix xdp crash in soft reset error path
> > 
> > This commit fixes a NULL pointer dereference that occurs when
> > idpf_vport_open() fails during soft reset. The fix restores
> > vport->xdp_prog in the error path and updates the restart check in
> > idpf_xsk_pool_setup() to use IDPF_VPORT_UP instead of netif_running().
> > 
> > > Fixes: 3d57b2c00f09 ("idpf: add XSk pool initialization")
> > 
> > The Fixes: tag may not be targeting the correct commit. The primary bug
> > being fixed is the NULL pointer dereference crash in idpf_xdp_setup_prog()
> > that occurs when soft reset fails and vport->xdp_prog is not restored.
> 
> This is not exactly true, this is just one of the instances that would
> cause idpf_qp_switch() to be called. [1]
> 
> > 
> > Looking at the git history, this missing restoration was introduced in
> > commit 705457e7211f ("idpf: implement XDP_SETUP_PROG in ndo_bpf for
> > splitq"), where idpf_xdp_setup_prog() was first implemented. While commit
> > 3d57b2c00f09 introduced the secondary issue with the netif_running()
> > check, the main crash fix addresses code from commit 705457e7211f.
> > 
> > Should the Fixes: tag point to commit 705457e7211f instead?
> 
> The reason I chose commit 3d57b2c00f09 is because it is the commit
> introducing the function where the crash is occurring:
> [ 3179.284770] RIP: 0010:idpf_find_rxq_vec+0x17/0x30 [idpf]
> ...
> [ 3179.291937] Call Trace:
> [ 3179.292392]  <TASK>
> [ 3179.292843]  idpf_qp_switch+0x25/0x820 [idpf]
> 
> The setting of the restart variable is where the above commits "meet",
> in that both conditions - netif_ruinning() and idpf_xdp_enabled() [1]
> can be wrong:
> https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git/tree/drivers/net/ethernet/intel/idpf/xsk.c#n571
> 
> which would end up calling idpf_qp_switch() instead of taking the
> alternate path:
> 	restart = idpf_xdp_enabled(vport) && netif_running(vport->netdev);
> 	if (!restart)
> 		goto pool;
> 
> Which was introduced by 3d57b2c00f09.

Thanks for the clarification.
I agree that using 3d57b2c00f09 makes sense.

...

      reply	other threads:[~2026-03-21  9:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19 22:41 [PATCH iwl-net v2] idpf: fix xdp crash in soft reset error path Emil Tantilov
2026-03-20 17:48 ` Simon Horman
2026-03-20 21:35   ` Tantilov, Emil S
2026-03-21  9:17     ` Simon Horman [this message]

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=20260321091753.GT74886@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=aleksandr.loktionov@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=decot@google.com \
    --cc=edumazet@google.com \
    --cc=emil.s.tantilov@intel.com \
    --cc=hawk@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=sdf@fomichev.me \
    --cc=stable@vger.kernel.org \
    --cc=willemb@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