Rust for Linux List
 help / color / mirror / Atom feed
From: Boqun Feng <boqun@kernel.org>
To: Shrikanth Hegde <sshegde@linux.ibm.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@kernel.org>, "Will Deacon" <will@kernel.org>,
	"Waiman Long" <longman@redhat.com>, "Gary Guo" <gary@garyguo.net>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Lyude Paul" <lyude@redhat.com>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Danilo Krummrich" <dakr@kernel.org>,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v4 05/17] irq & spin_lock: Add counted interrupt disabling/enabling
Date: Wed, 5 Aug 2026 10:38:07 -0700	[thread overview]
Message-ID: <anN0_z--Mnuw3IK-@tardis.local> (raw)
In-Reply-To: <f1d73456-73ee-46e3-aaf7-6a6fe40f3196@linux.ibm.com>

On Wed, Aug 05, 2026 at 10:23:20PM +0530, Shrikanth Hegde wrote:
> Hi Boqun.
> 
> On 8/5/26 8:41 PM, Boqun Feng wrote:
> > On Wed, Aug 05, 2026 at 08:26:49PM +0530, Shrikanth Hegde wrote:
> > > 
> > > 
> > > On 8/5/26 7:50 PM, Boqun Feng wrote:
> > > > On Wed, Aug 05, 2026 at 07:40:18PM +0530, Shrikanth Hegde wrote:
> > > > > 
> > > > > Hi Boqun,
> > > > > 
> > > > > > 
> > > > > > Something as below? Going to send it to kernel build bot and see if it
> > > > > > works for all configs.
> > > > > > 
> > > > > > ----------------->8
> > > > > > diff --git a/include/linux/interrupt_rc.h b/include/linux/interrupt_rc.h
> > > > > > index b9a7f05ecf42..39f30bc65548 100644
> > > > > > --- a/include/linux/interrupt_rc.h
> > > > > > +++ b/include/linux/interrupt_rc.h
> > > > > > @@ -12,6 +12,7 @@
> > > > > >      */
> > > > > > 
> > > > > >     #include <linux/irqflags.h>
> > > > > > +#include <linux/debug_locks.h>
> > > > > >     #include <linux/preempt.h>
> > > > > >     #include <linux/processor.h>
> > > > > >     #include <linux/smp.h>
> > > > > > @@ -63,6 +64,12 @@ static inline void local_interrupt_disable(void)
> > > > > > 
> > > > > >            new_count = hardirq_disable_enter();
> > > > > > 
> > > > > > +       /* Is hardirq disable count overflow soon? */
> > > > > > +       if (IS_ENABLED(CONFIG_DEBUG_PREEMPT))
> > > > > > +               DEBUG_LOCKS_WARN_ON((new_count & HARDIRQ_DISABLE_MASK) +
> > > > > > +                                   (10 << HARDIRQ_DISABLE_SHIFT) >
> > > > > > +                                   HARDIRQ_DISABLE_MASK);
> > > > > > +
> > > > > 
> > > > > This needs a return here right? Else we will see warning for 10 times
> > > > > and then overflow happens and we will call _local_interrupt_disable. No?
> > 
> > Oh, seems I overlooked something... could you elaborate on this? What's
> > the scenario in your mind? You said we hit 10 times warning and *then*
> > overflow?
> > 
> 
> 
> (the "10 times" wording was for the possible wraparound.
> I didn't know DEBUG_LOCKS_WARN_ON() will turn debug_locks
> off after the first warning, I thought it will print 10 times.)
> 
> Main concern is the wraparound itself. If the HARDIRQ_DISABLE field reaches
> 0xff and we increment it once more, the field becomes zero after masking
> (ff + 1 -> 100 in the shifted field). Then local_interrupt_enable() can
> observe:
> 
>         (new_count & HARDIRQ_DISABLE_MASK) == 0
> 
> and treat it as the outermost enable, potentially calling
> _local_interrupt_enable() while there are still outstanding logical
> local_interrupt_disable() users.
> 
> So I think the useful debug check is one that catches the count before it
> gets close enough to wrap. Thing I wanted to avoid is silently making the
> HARDIRQ_DISABLE field look like zero after overflow.
> 

Given that the detection is only on debug kernel, I think the damage of
keeping increment after warn triggered is low (this is assuming that we
can detect all the issues with the debug kernel, similar treatment as
the preempt_count nowadays). However, your suggestion does look better
for the corner cases and it's a better damage control, so I will add the
return part, thank you!

For the future, we need better detection and report for these counters
for sure.

Regards,
Boqun

> Whether it returns or just warns, I am not sure. As recovery may
> not be easy. It is meant more to be a damage contol than recovery.
> 
> 
> My line of thought is,
> 
> If we return after debug checks in local_interrupt_disable(), we wont advance the preempt count
> further, so it wont wrap around. Now, there will be corresponding local_interrupt_enable(),
> at some point it will reach 0, we enable the interrupts. There will be some more
> local_interrupt_enable() still, but they will be caught with your debug check in
> local_interrupt_enable() and preempt count won't be decremented further.
> So if we put return we may have a damage control.
> 
> > > > > 
> > > > 
> > > > DEBUG_LOCKS_WARN_ON() uses debug_locks_off() to avoid this, so we won't
> > > > see it 10 times. The reason not using return here, because we would
> > > > introduce unpaired local_interrupt_disable() if we returned:
> > > 
> > > Yes, it could be a weird case if the overflow actually happens.
> > > So just warning maybe enough to catch such callers.
> > > 
> > > Maybe your kunit test can actually help test the behavior with the loop
> > > count.
> > > 
> > > > 
> > > > 	// hardirq disable count is n
> > > > 	local_interrupt_disable(); // hardirq disable count is n + 1
> > > > 
> > > > 	local_interrupt_disable(); <- trigger the warning, if we return
> > > > 				   // hardirq disable count is n + 1
> > > 
> > > Likely i am missing to understand.
> > > 
> > 
> > No, it was me who misunderstand ;-)
> > 
> > > Isn't the count incremented earlier than return?
> > > I.e even if return happens it should be n + 2 right?
> > > 
> > 
> > Yeah, you're right, but then why do we want to return earlier? Since the
> > following if:
> > 
> > 	if ((new_count & HARDIRQ_DISABLE_MASK) == HARDIRQ_DISABLE_OFFSET)
> > 
> > will be false, and we will just return from the function, no?
> > 
> > Regards,
> > Boqun
> > 
> > > > 
> > > > 	local_interrupt_enable(); // hardirq disable count is n
> > > > 
> > > > 	local_interrupt_enable(); // hardirq disable count is n - 1
> > > > 
> > > > Regards,
> > > > Boqun
> > > > 
> > > > > Not sure, if below is any better? (Igore whitespace mangling)
> > > > > 
> > > > > if (IS_ENABLED(CONFIG_DEBUG_PREEMPT) &&
> > > > >       DEBUG_LOCKS_WARN_ON((preempt_count() & HARDIRQ_DISABLE_MASK) >=
> > > > > 			 HARDIRQ_DISABLE_MASK - (10 << HARDIRQ_DISABLE_SHIFT)))
> > > > > 	return;
> > > > > 
> > > > > >            /* Interrupts can happen here, but it's OK, see __irq_exit_rcu(). */
> > > > > > 
> > > > > >            if ((new_count & HARDIRQ_DISABLE_MASK) == HARDIRQ_DISABLE_OFFSET)
> > > > > > @@ -73,6 +80,11 @@ static inline void local_interrupt_enable(void)
> > > > > >     {
> > > > > >            int new_count;
> > > > > > 
> > > > > > +       /* Unpaired local_interrupt_enable()? Warn and abort. */
> > > > > > +       if (IS_ENABLED(CONFIG_DEBUG_PREEMPT) &&
> > > > > > +           DEBUG_LOCKS_WARN_ON((preempt_count() & HARDIRQ_DISABLE_MASK) == 0))
> > > > > > +               return;
> > > > > > +
> > > > > >            new_count = hardirq_disable_exit();
> > > > > > 
> > > > > >            if ((new_count & HARDIRQ_DISABLE_MASK) == 0) >
> > > > > 
> > > 
> 

  reply	other threads:[~2026-08-05 17:38 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 16:14 [PATCH v4 00/17] Refcounted interrupt disable and SpinLockIrq for Rust Boqun Feng
2026-08-04 16:14 ` [PATCH v4 01/17] preempt: Track NMI nesting to separate per-CPU counter Boqun Feng
2026-08-04 16:14 ` [PATCH v4 02/17] preempt: Introduce HARDIRQ_DISABLE_BITS Boqun Feng
2026-08-05  6:31   ` Peter Zijlstra
2026-08-05  6:59     ` Boqun Feng
2026-08-04 16:14 ` [PATCH v4 03/17] preempt: Introduce __preempt_count_{sub,add}_return() Boqun Feng
2026-08-04 16:14 ` [PATCH v4 04/17] openrisc: Include <linux/cpumask.h> in smp.h Boqun Feng
2026-08-04 16:14 ` [PATCH v4 05/17] irq & spin_lock: Add counted interrupt disabling/enabling Boqun Feng
2026-08-04 18:20   ` Boqun Feng
2026-08-04 18:26   ` [PATCH v4.1 " Boqun Feng
2026-08-04 20:51   ` [PATCH v4 " Shrikanth Hegde
2026-08-04 21:08     ` Boqun Feng
2026-08-05  6:36       ` Peter Zijlstra
2026-08-05  7:07         ` Boqun Feng
2026-08-05  7:09           ` Shrikanth Hegde
2026-08-05  7:19             ` Boqun Feng
2026-08-05 13:53               ` Boqun Feng
2026-08-05 14:10                 ` Shrikanth Hegde
2026-08-05 14:20                   ` Boqun Feng
2026-08-05 14:56                     ` Shrikanth Hegde
2026-08-05 15:11                       ` Boqun Feng
2026-08-05 16:53                         ` Shrikanth Hegde
2026-08-05 17:38                           ` Boqun Feng [this message]
2026-08-05 18:07                       ` Boqun Feng
2026-08-04 16:14 ` [PATCH v4 06/17] irq: Add KUnit test for refcounted interrupt enable/disable Boqun Feng
2026-08-04 16:14 ` [PATCH v4 07/17] locking: Switch to _irq_{disable,enable}() variants in cleanup guards Boqun Feng
2026-08-04 16:14 ` [PATCH v4 08/17] sched: Remove the unused preempt_offset parameter of __cant_sleep() Boqun Feng
2026-08-04 16:14 ` [PATCH v4 09/17] sched: Avoid signed comparison of preempt_count() in __cant_migrate() Boqun Feng
2026-08-04 16:14 ` [PATCH v4 10/17] preempt: Introduce HAS_SEPARATE_PREEMPT_RESCHED_BITS Boqun Feng
2026-08-04 20:11   ` Shrikanth Hegde
2026-08-05  6:54     ` Boqun Feng
2026-08-05  7:15       ` Shrikanth Hegde
2026-08-05  7:27         ` Boqun Feng
2026-08-06  0:58       ` Boqun Feng
2026-08-04 21:09   ` Shrikanth Hegde
2026-08-04 23:14     ` Boqun Feng
2026-08-04 16:14 ` [PATCH v4 11/17] arm64: sched/preempt: Enable HAS_SEPARATE_PREEMPT_RESCHED_BITS Boqun Feng
2026-08-04 16:14 ` [PATCH v4 12/17] s390/preempt: " Boqun Feng
2026-08-04 20:27   ` Shrikanth Hegde
2026-08-05  9:42     ` Peter Zijlstra
2026-08-05 12:37       ` Shrikanth Hegde
2026-08-04 16:14 ` [PATCH v4 13/17] rust: Introduce interrupt module Boqun Feng
2026-08-04 16:14 ` [PATCH v4 14/17] rust: helper: Add spin_{un,}lock_irq_{enable,disable}() helpers Boqun Feng
2026-08-04 16:14 ` [PATCH v4 15/17] rust: sync: Use super::* in spinlock.rs Boqun Feng
2026-08-04 16:14 ` [PATCH v4 16/17] rust: sync: Add SpinLockIrq Boqun Feng
2026-08-04 16:14 ` [PATCH v4 17/17] rust: sync: Introduce SpinLockIrq::lock_with() and friends Boqun Feng

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=anN0_z--Mnuw3IK-@tardis.local \
    --to=boqun@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=lyude@redhat.com \
    --cc=mingo@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sshegde@linux.ibm.com \
    --cc=will@kernel.org \
    --cc=work@onurozkan.dev \
    /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