public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Joel Fernandes <joelagnelf@nvidia.com>
Cc: Lyude Paul <lyude@redhat.com>,
	rust-for-linux@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Boqun Feng <boqun.feng@gmail.com>,
	linux-kernel@vger.kernel.org,
	Daniel Almeida <daniel.almeida@collabora.com>,
	Danilo Krummrich <dakr@kernel.org>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alex Gaynor <alex.gaynor@gmail.com>, Gary Guo <gary@garyguo.net>,
	Bj??rn Roy Baron <bjorn3_gh@protonmail.com>,
	Benno Lossin <lossin@kernel.org>,
	Andreas Hindborg <a.hindborg@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	Trevor Gross <tmgross@umich.edu>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	Ryo Takakura <ryotkkr98@gmail.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	"open list:CPU FREQUENCY SCALING FRAMEWORK"
	<linux-pm@vger.kernel.org>
Subject: Re: [PATCH v13 01/17] preempt: Track NMI nesting to separate per-CPU counter
Date: Tue, 14 Oct 2025 21:43:49 +0200	[thread overview]
Message-ID: <20251014194349.GC1206438@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <4a237ec0-05ae-439b-a1cb-6b7f451c0d7e@nvidia.com>

On Tue, Oct 14, 2025 at 01:55:47PM -0400, Joel Fernandes wrote:
> 
> 
> On 10/14/2025 6:48 AM, Peter Zijlstra wrote:
> > On Mon, Oct 13, 2025 at 11:48:03AM -0400, Lyude Paul wrote:
> > 
> >>  #define __nmi_enter()						\
> >>  	do {							\
> >>  		lockdep_off();					\
> >>  		arch_nmi_enter();				\
> >> -		BUG_ON(in_nmi() == NMI_MASK);			\
> >> -		__preempt_count_add(NMI_OFFSET + HARDIRQ_OFFSET);	\
> >> +		BUG_ON(__this_cpu_read(nmi_nesting) == UINT_MAX);	\
> >> +		__this_cpu_inc(nmi_nesting);			\
> > 
> > An NMI that nests from here..
> > 
> >> +		__preempt_count_add(HARDIRQ_OFFSET);		\
> >> +		if (__this_cpu_read(nmi_nesting) == 1)		\
> > 
> > .. until here, will see nmi_nesting > 1 and not set NMI_OFFSET.
> 
> This is true, I can cure it by setting NMI_OFFSET unconditionally when
> nmi_nesting >= 1. Then the outer most NMI will then reset it. I think that will
> work. Do you see any other issue with doing so?

unconditionally set NMI_FFSET, regardless of nmi_nesting
and only clear on exit when nmi_nesting == 0.

Notably, when you use u64 __preempt_count, you can limit this to 32bit
only. The NMI nesting can happen in the single instruction window
between ADD and ADC. But on 64bit you don't have that gap and so don't
need to fix it.

  reply	other threads:[~2025-10-14 19:44 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-13 15:48 [PATCH v13 00/17] Refcounted interrupts, SpinLockIrq for rust Lyude Paul
2025-10-13 15:48 ` [PATCH v13 01/17] preempt: Track NMI nesting to separate per-CPU counter Lyude Paul
2025-10-13 16:19   ` Lyude Paul
2025-10-13 16:32     ` Miguel Ojeda
2025-10-13 20:00   ` Peter Zijlstra
2025-10-13 21:27     ` Joel Fernandes
2025-10-14  8:25       ` Peter Zijlstra
2025-10-14 17:59         ` Joel Fernandes
2025-10-14 19:37           ` Peter Zijlstra
2025-10-14 10:48   ` Peter Zijlstra
2025-10-14 17:55     ` Joel Fernandes
2025-10-14 19:43       ` Peter Zijlstra [this message]
2025-10-14 22:05         ` Joel Fernandes
2025-10-20 20:44         ` Joel Fernandes
2025-10-30 22:56           ` Joel Fernandes
2025-10-13 15:48 ` [PATCH v13 02/17] preempt: Reduce NMI_MASK to single bit and restore HARDIRQ_BITS Lyude Paul
2025-11-04 12:15   ` Andreas Hindborg
2025-10-13 15:48 ` [PATCH v13 03/17] preempt: Introduce HARDIRQ_DISABLE_BITS Lyude Paul
2025-10-31 14:59   ` Andreas Hindborg
2025-10-31 19:59     ` Boqun Feng
2025-10-13 15:48 ` [PATCH v13 04/17] preempt: Introduce __preempt_count_{sub, add}_return() Lyude Paul
2025-11-04 12:30   ` Andreas Hindborg
2025-10-13 15:48 ` [PATCH v13 05/17] irq & spin_lock: Add counted interrupt disabling/enabling Lyude Paul
2025-10-15 20:54   ` Bart Van Assche
2025-10-16  8:15     ` Peter Zijlstra
2025-10-17  6:44       ` Boqun Feng
2025-10-16 21:24   ` David Laight
2025-10-17  6:48     ` Boqun Feng
2025-11-04 12:45   ` Andreas Hindborg
2025-11-19 21:47     ` Lyude Paul
2025-10-13 15:48 ` [PATCH v13 06/17] irq: Add KUnit test for refcounted interrupt enable/disable Lyude Paul
2025-10-13 15:48 ` [PATCH v13 07/17] rust: Introduce interrupt module Lyude Paul
2025-11-04 12:55   ` Andreas Hindborg
2025-10-13 15:48 ` [PATCH v13 08/17] rust: helper: Add spin_{un,}lock_irq_{enable,disable}() helpers Lyude Paul
2025-11-04 12:56   ` Andreas Hindborg
2025-10-13 15:48 ` [PATCH v13 09/17] rust: sync: Add SpinLockIrq Lyude Paul
2025-11-04 13:09   ` Andreas Hindborg
2025-10-13 15:48 ` [PATCH v13 10/17] rust: sync: Introduce lock::Backend::Context Lyude Paul
2025-10-13 15:48 ` [PATCH v13 11/17] rust: sync: lock: Add `Backend::BackendInContext` Lyude Paul
2025-11-05 12:45   ` Andreas Hindborg
2025-10-13 15:48 ` [PATCH v13 12/17] rust: sync: lock/global: Rename B to G in trait bounds Lyude Paul
2025-10-13 15:48 ` [PATCH v13 13/17] rust: sync: Add a lifetime parameter to lock::global::GlobalGuard Lyude Paul
2025-10-13 15:48 ` [PATCH v13 14/17] rust: sync: Expose lock::Backend Lyude Paul
2025-10-13 15:48 ` [PATCH v13 15/17] rust: sync: lock/global: Add Backend parameter to GlobalGuard Lyude Paul
2025-10-13 15:48 ` [PATCH v13 16/17] rust: sync: lock/global: Add BackendInContext support to GlobalLock Lyude Paul
2025-10-13 15:48 ` [PATCH v13 17/17] locking: Switch to _irq_{disable,enable}() variants in cleanup guards Lyude Paul

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=20251014194349.GC1206438@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bigeasy@linutronix.de \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=joelagnelf@nvidia.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=lossin@kernel.org \
    --cc=lyude@redhat.com \
    --cc=mingo@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=ryotkkr98@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=tmgross@umich.edu \
    --cc=urezki@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=viresh.kumar@linaro.org \
    /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