mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
To: <choiniere.vincent@hydroquebec.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	<intel-wired-lan@lists.osuosl.org>
Cc: Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
	Wojciech Drewek <wojciech.drewek@intel.com>,
	Paul Menzel <pmenzel@molgen.mpg.de>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<stable@vger.kernel.org>
Subject: Re: [PATCH net v2] ice: fix Tx hang dump using stale tx_buf[0].skb
Date: Wed, 28 Oct 2026 15:41:14 +0100	[thread overview]
Message-ID: <1950d325-384c-46dd-aa24-3d3ee561b2dd@intel.com> (raw)
In-Reply-To: <20261026-ice-tx-hang-dump-v2-1-e2136ef2c5dc@hydroquebec.com>

On 10/26/26 2:30 PM, Vincent Choiniere via B4 Relay wrote:
> From: Vincent Choiniere <choiniere.vincent@hydroquebec.com>
> 
> ice_tx_hang_reporter_dump() always reads tx_ring->tx_buf[0].skb,
> regardless of next_to_clean. The Tx cleanup path frees the skb and
> marks the buffer empty without clearing the skb pointer, so slot 0 can
> hold a stale pointer. A NULL check alone does not cover this, and
> devlink_fmsg_dump_skb() can fault on the freed skb.
> 
> Using tx_buf[next_to_clean] alone does not fix the lifetime issues.
> The dump runs from the service task without synchronization with Tx
> cleanup or ring replacement:
> 
> - ice_clean_tx_irq() can free the skb at next_to_clean while the
>    report is being prepared. It calls napi_consume_skb() before
>    marking the buffer empty.
> - The ring saved by ice_tx_timeout() can be replaced or freed before
>    the service task runs. ethtool -G replaces the ring contents and
>    frees tx_buf and desc, while ethtool -L can free whole rings.
> 
> Record the queue index, next_to_clean and next_to_use at timeout time.
> Before reporting, take RTNL and check that the saved ring is still
> one of the PF VSI Tx rings and that the VSI is up. Copy the
> descriptors and IRQ name while the ring storage is protected against
> replacement. If the ring cannot be used or the copy cannot be made,
> report only the values recorded at timeout time.
> 
> Tx cleanup can still run while the ring state is copied, so do not
> dereference the skb. Retain only its pointer value in the dump and
> remove the skb contents.
> 
> Release RTNL before calling devlink_health_report(), which takes the
> devlink instance lock. Build the dump from the copied data and free
> the descriptor copy after reporting.
> 
> Observed on an E810 PF passed through to a KVM guest with Ubuntu
> kernel 7.0.0-14 (PREEMPT_RT and a local scheduler patch): a delayed
> queue IRQ led to a Tx timeout and a page fault in
> devlink_fmsg_dump_skb():
> 
>   BUG: unable to handle page fault for address: 0000000004cd0c11
>   Workqueue: ice ice_service_task [ice]
>   RIP: devlink_fmsg_dump_skb+0x2d8/0x5d0
>   Call Trace:
>    ice_tx_hang_reporter_dump+0x1ce/0x210 [ice]
>    devlink_health_do_dump+0xcc/0x190
>    devlink_health_report+0x1d7/0x260
>    ice_report_tx_hang+0x7d/0xa0 [ice]
> 
> Fixes: 2a82874a3b7b ("ice: add Tx hang devlink health reporter")
> Link: https://lore.kernel.org/all/20260327072332.130320-1-aleksandr.loktionov@intel.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Vincent Choiniere <choiniere.vincent@hydroquebec.com>
> ---
> Changes in v2:
> - Validate the saved ring under RTNL before dereferencing it from
>    the service task, and restrict snapshots to the PF VSI while it
>    is up (Sashiko).
> - Check next_to_clean against count before indexing tx_buf, and
>    copy the descriptors and IRQ name while ring replacement is
>    excluded (Sashiko).
> - Stop dereferencing the skb and remove its contents from the dump.
>    Keep only its pointer value (Sashiko).
> - Release RTNL before reporting to preserve the devlink instance
>    lock ordering.
> - Record the queue index and ring indices at timeout time as a
>    fallback when a snapshot cannot be made.
> - Drop Paul's Reviewed-by because the patch changed substantially.

lot's of changes and code, but rather nothing controversial, I'm
generally happy with it, one nitpick from me inline, and otherwise:

Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>

> +static void ice_tx_hang_snapshot(struct ice_pf *pf, struct ice_tx_ring *tx_ring,
> +				 struct ice_tx_hang_event *ev)
> +{
> +	struct ice_vsi *vsi = ice_get_main_vsi(pf);
> +	struct ice_q_vector *q_vector;
> +	struct ice_tx_buf *tx_buf;
> +	unsigned int i;
> +	u16 ntc, ntu;
> +	void *desc;
> +	u32 size;
> +
> +	ASSERT_RTNL();
> +
> +	if (!tx_ring || !vsi || !vsi->tx_rings ||
> +	    test_bit(ICE_VSI_DOWN, vsi->state))
> +		return;
> +
> +	ice_for_each_txq(vsi, i)
> +		if (vsi->tx_rings[i] == tx_ring)
> +			break;
> +	if (i == vsi->num_txq)
> +		return;
> +
> +	q_vector = tx_ring->q_vector;
> +	if (!q_vector || !tx_ring->desc || !tx_ring->tx_buf || !tx_ring->count)
> +		return;
> +
> +	size = tx_ring->count * sizeof(struct ice_tx_desc);
> +	desc = kvmalloc(size, GFP_KERNEL);
> +	if (!desc)
> +		return;
> +
> +	ntc = READ_ONCE(tx_ring->next_to_clean);
> +	ntu = READ_ONCE(tx_ring->next_to_use);
> +
> +	if (ntc < tx_ring->count) {
> +		tx_buf = &tx_ring->tx_buf[ntc];
> +		if (tx_buf->type == ICE_TX_BUF_SKB)
> +			ev->skb_ptr = READ_ONCE(tx_buf->skb);
> +
> +		memcpy(desc, tx_ring->desc, size);
> +		ev->next_to_clean = ntc;
> +		ev->next_to_use = ntu;
> +		strscpy(ev->irq_name, q_vector->name);
> +		ev->desc_ptr = tx_ring->desc;
> +		ev->dma = tx_ring->dma;
> +		ev->desc_size = size;
> +		ev->desc = desc;
> +	}
> +
> +	if (!ev->desc)

this is abuse of ev and bad style, instead just glue an else to the
previous if, basically:
      if (ntc < tx_ring->count) { .... } else { kvfree(desc); }

> +		kvfree(desc);
>   }


  reply	other threads:[~2026-10-28 14:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-26 13:30 Vincent Choiniere via B4 Relay
2026-10-28 14:41 ` Przemek Kitszel [this message]
2026-10-29  2:37 ` netdev-bot+sashiko

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=1950d325-384c-46dd-aa24-3d3ee561b2dd@intel.com \
    --to=przemyslaw.kitszel@intel.com \
    --cc=aleksandr.loktionov@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=choiniere.vincent@hydroquebec.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pmenzel@molgen.mpg.de \
    --cc=stable@vger.kernel.org \
    --cc=wojciech.drewek@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

all inboxes | Powered by JetHome®