All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dragos Tatulea <dtatulea@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Nimrod Oren <noren@nvidia.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [TEST] CX7 timeouts on reconfig w/ page pool failure injection
Date: Mon, 17 Aug 2026 14:31:55 +0200	[thread overview]
Message-ID: <1c767f25-fa23-44aa-b8d7-b1374627fc9a@nvidia.com> (raw)
In-Reply-To: <20260812154101.72b64936@kernel.org>

Hi,

On 13.08.26 00:41, Jakub Kicinski wrote:
> On Wed, 12 Aug 2026 21:48:31 +0200 Dragos Tatulea wrote:
>>> Ack, I'll send a patch to bump the timeout shortly.
>>>
>>> That said, the page pool warnings were probabilistic to begin with.
>>> And they were hit in page_pool_unref_netmem(), I think _some_ bug
>>> must still be there?
>>>
>>> IOW mlx5e_page_release_fragmented() is draining more references than
>>> the pp page use counter, that's not normal whether some command timeout
>>> out or not.  
>> Yes, this shouldn't happen.
>>
>> You mentioned tag net-next-hw-2026-07-03--00-00 as the first where the
>> crash occurred. Do you know if it ran before without crashing? I can't
>> find older data in nipa. And there's nothing that seems relevant around
>> that timeframe. I'm thinking that this issue could be older.
> 
> The data should be there but I think there may be limits on how much
> the DB returns. Anyway, querying directly - looks like until ~june
> there was something missing in the kconfig so the test was skipping.
> But here is a June 1st run which passes:
> 
> https://netdev.bots.linux.dev/logview.html?f=/logs/hwksft/CX7-dbg/results/672642/test-outputs/35-pp-alloc-fail-py/stdout
> 
> so either it was running and not crashing for all of june...
> or our crash tracking was broken in June :)
There were 2 corner cases that were missed by the last fix in
the area regarding handling of XDP buffer geometry changes
(fragments get deleted):
- napi_alloc_skb() error path. Probably this is the one one
  that triggered the crash, it occurs when injecting an error
  there.
- XDP drop path. Doesn't make sense but it is possible.

We have a fix in the pipeline for these.

Thanks,
Dragos

      reply	other threads:[~2026-08-17 12:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 16:45 [TEST] CX7 timeouts on reconfig w/ page pool failure injection Jakub Kicinski
2026-08-04 17:16 ` Dragos Tatulea
2026-08-04 19:44   ` Jakub Kicinski
2026-08-11  7:20 ` Nimrod Oren
2026-08-11 15:04   ` Jakub Kicinski
2026-08-11 16:57     ` Nimrod Oren
2026-08-11 17:38       ` Jakub Kicinski
2026-08-12 16:31         ` Nimrod Oren
2026-08-12 16:59           ` Jakub Kicinski
2026-08-12 19:48             ` Dragos Tatulea
2026-08-12 22:41               ` Jakub Kicinski
2026-08-17 12:31                 ` Dragos Tatulea [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=1c767f25-fa23-44aa-b8d7-b1374627fc9a@nvidia.com \
    --to=dtatulea@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=noren@nvidia.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 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.