From: Thomas Gleixner <tglx@kernel.org>
To: Joe Damato <joe@dama.to>
Cc: intel-wired-lan@lists.osuosl.org,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
netdev@vger.kernel.org
Subject: Re: [Intel-wired-lan] i40e: Fix preempt count leak in napi poll tracepoint
Date: Tue, 10 Feb 2026 01:25:11 +0100 [thread overview]
Message-ID: <877bslbg2g.ffs@tglx> (raw)
In-Reply-To: <87a4xhbk6a.ffs@tglx>
On Mon, Feb 09 2026 at 23:56, Thomas Gleixner wrote:
> On Mon, Feb 09 2026 at 14:07, Joe Damato wrote:
>
>> On Sat, Feb 07, 2026 at 11:50:23AM +0100, Thomas Gleixner wrote:
>>> Using get_cpu() in the tracepoint assignment causes an obvious preempt
>>> count leak because nothing invokes put_cpu() to undo it:
>>>
>>> softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?
>>>
>>> This clearly has seen a lot of testing in the last 3+ years...
>>
>> I'm the author who introduced the bug. FWIW, I did use it quite a bit when I
>> had i40e devices.
>
> Right, but always with PREEMPT_NONE and no debug option which would
> enforce PREEMPT_COUNT ...
Forgot to mention that's what is required before submitting patches
according to Documentation/process/submit-checklist.rst
But who cares about documentation aside of the people who write it?
Thanks,
tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@kernel.org>
To: Joe Damato <joe@dama.to>
Cc: intel-wired-lan@lists.osuosl.org,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
netdev@vger.kernel.org
Subject: Re: i40e: Fix preempt count leak in napi poll tracepoint
Date: Tue, 10 Feb 2026 01:25:11 +0100 [thread overview]
Message-ID: <877bslbg2g.ffs@tglx> (raw)
In-Reply-To: <87a4xhbk6a.ffs@tglx>
On Mon, Feb 09 2026 at 23:56, Thomas Gleixner wrote:
> On Mon, Feb 09 2026 at 14:07, Joe Damato wrote:
>
>> On Sat, Feb 07, 2026 at 11:50:23AM +0100, Thomas Gleixner wrote:
>>> Using get_cpu() in the tracepoint assignment causes an obvious preempt
>>> count leak because nothing invokes put_cpu() to undo it:
>>>
>>> softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?
>>>
>>> This clearly has seen a lot of testing in the last 3+ years...
>>
>> I'm the author who introduced the bug. FWIW, I did use it quite a bit when I
>> had i40e devices.
>
> Right, but always with PREEMPT_NONE and no debug option which would
> enforce PREEMPT_COUNT ...
Forgot to mention that's what is required before submitting patches
according to Documentation/process/submit-checklist.rst
But who cares about documentation aside of the people who write it?
Thanks,
tglx
next prev parent reply other threads:[~2026-02-10 0:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-07 10:50 [Intel-wired-lan] i40e: Fix preempt count leak in napi poll tracepoint Thomas Gleixner
2026-02-07 10:50 ` Thomas Gleixner
2026-02-09 22:07 ` [Intel-wired-lan] " Joe Damato
2026-02-09 22:07 ` Joe Damato
2026-02-09 22:56 ` [Intel-wired-lan] " Thomas Gleixner
2026-02-09 22:56 ` Thomas Gleixner
2026-02-10 0:25 ` Thomas Gleixner [this message]
2026-02-10 0:25 ` Thomas Gleixner
2026-02-10 2:58 ` [Intel-wired-lan] " Joe Damato
2026-02-10 2:58 ` Joe Damato
2026-02-10 7:17 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-02-10 7:17 ` Loktionov, Aleksandr
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=877bslbg2g.ffs@tglx \
--to=tglx@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=joe@dama.to \
--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 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.