netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Michal Kubiak <michal.kubiak@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, maciej.fijalkowski@intel.com,
	aleksander.lobakin@intel.com, przemyslaw.kitszel@intel.com,
	dawid.osuchowski@linux.intel.com, jacob.e.keller@intel.com,
	jbrandeburg@cloudflare.com, netdev@vger.kernel.org,
	Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Subject: Re: [PATCH iwl-net v3 1/3] ice: fix Tx scheduler error handling in XDP callback
Date: Thu, 15 May 2025 12:46:15 +0100	[thread overview]
Message-ID: <20250515114615.GU3339421@horms.kernel.org> (raw)
In-Reply-To: <20250513105529.241745-2-michal.kubiak@intel.com>

On Tue, May 13, 2025 at 12:55:27PM +0200, Michal Kubiak wrote:
> When the XDP program is loaded, the XDP callback adds new Tx queues.
> This means that the callback must update the Tx scheduler with the new
> queue number. In the event of a Tx scheduler failure, the XDP callback
> should also fail and roll back any changes previously made for XDP
> preparation.
> 
> The previous implementation had a bug that not all changes made by the
> XDP callback were rolled back. This caused the crash with the following
> call trace:
> 
> [  +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5
> [  +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI
> [  +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary)
> [  +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022
> [  +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice]
> 
> [...]
> 
> [  +0.002715] Call Trace:
> [  +0.002452]  <IRQ>
> [  +0.002021]  ? __die_body.cold+0x19/0x29
> [  +0.003922]  ? die_addr+0x3c/0x60
> [  +0.003319]  ? exc_general_protection+0x17c/0x400
> [  +0.004707]  ? asm_exc_general_protection+0x26/0x30
> [  +0.004879]  ? __ice_update_sample+0x39/0xe0 [ice]
> [  +0.004835]  ice_napi_poll+0x665/0x680 [ice]
> [  +0.004320]  __napi_poll+0x28/0x190
> [  +0.003500]  net_rx_action+0x198/0x360
> [  +0.003752]  ? update_rq_clock+0x39/0x220
> [  +0.004013]  handle_softirqs+0xf1/0x340
> [  +0.003840]  ? sched_clock_cpu+0xf/0x1f0
> [  +0.003925]  __irq_exit_rcu+0xc2/0xe0
> [  +0.003665]  common_interrupt+0x85/0xa0
> [  +0.003839]  </IRQ>
> [  +0.002098]  <TASK>
> [  +0.002106]  asm_common_interrupt+0x26/0x40
> [  +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690
> 
> Fix this by performing the missing unmapping of XDP queues from
> q_vectors and setting the XDP rings pointer back to NULL after all those
> queues are released.
> Also, add an immediate exit from the XDP callback in case of ring
> preparation failure.
> 
> Fixes: efc2214b6047 ("ice: Add support for XDP")
> Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Michal Kubiak <michal.kubiak@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Reviewed-by: Simon Horman <horms@kernel.org>


  reply	other threads:[~2025-05-15 11:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-13 10:55 [PATCH iwl-net v3 0/3] Fix XDP loading on machines with many CPUs Michal Kubiak
2025-05-13 10:55 ` [PATCH iwl-net v3 1/3] ice: fix Tx scheduler error handling in XDP callback Michal Kubiak
2025-05-15 11:46   ` Simon Horman [this message]
2025-05-13 10:55 ` [PATCH iwl-net v3 2/3] ice: create new Tx scheduler nodes for new queues only Michal Kubiak
2025-05-15 11:46   ` Simon Horman
2025-05-13 10:55 ` [PATCH iwl-net v3 3/3] ice: fix rebuilding the Tx scheduler tree for large queue counts Michal Kubiak
2025-05-15 11:46   ` Simon Horman
2025-05-15 22:43 ` [PATCH iwl-net v3 0/3] Fix XDP loading on machines with many CPUs Jesse Brandeburg
2025-05-16 10:24   ` Michal Kubiak

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=20250515114615.GU3339421@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=aleksandr.loktionov@intel.com \
    --cc=dawid.osuchowski@linux.intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jbrandeburg@cloudflare.com \
    --cc=maciej.fijalkowski@intel.com \
    --cc=michal.kubiak@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=przemyslaw.kitszel@intel.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;
as well as URLs for NNTP newsgroup(s).