[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241024100538.GE9767@noisy.programming.kicks-ass.net>
Date: Thu, 24 Oct 2024 12:05:38 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Boqun Feng <boqun.feng@...il.com>, Dirk Behme <dirk.behme@...il.com>,
Lyude Paul <lyude@...hat.com>, rust-for-linux@...r.kernel.org,
Danilo Krummrich <dakr@...hat.com>, airlied@...hat.com,
Ingo Molnar <mingo@...hat.com>, will@...nel.org,
Waiman Long <longman@...hat.com>, linux-kernel@...r.kernel.org,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, wedsonaf@...il.com,
Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...sung.com>, aliceryhl@...gle.com,
Trevor Gross <tmgross@...ch.edu>
Subject: Re: [POC 1/6] irq & spin_lock: Add counted interrupt
disabling/enabling
On Wed, Oct 23, 2024 at 10:38:38PM +0200, Thomas Gleixner wrote:
> On Wed, Oct 23 2024 at 21:51, Peter Zijlstra wrote:
> > On Wed, Oct 23, 2024 at 09:34:27PM +0200, Thomas Gleixner wrote:
> >> On Thu, Oct 17 2024 at 22:51, Boqun Feng wrote:
> >> Ideally you make that part of the preemption count. Bit 24-30 are free
> >> (or we can move them around as needed). That's deep enough and you get
> >> the debug sanity checking of the preemption counter for free (might need
> >> some extra debug for this...)
> >
> > Urgh, so we've already had trouble that nested spinlocks bust through
> > the 0xff preempt mask (because lunacy).
>
> Seriously? Such overflow should just panic the kernel. That's broken by
> definition.
It will not panic, it will mostly work and randomly do weird things.
Only once you build with DEBUG_PREEMPT=y will you notice.
> > You sure you want to be this stingy with bits?
>
> Anything above 64 nest levels is beyond insane.
Agreed.
> But if we want to support insanity then we make preempt count 64 bit and
> be done with it. But no, I don't think that encouraging insanity is a
> good thing.
The problem is that in most release builds the overflow will be silent
and cause spurious weirdness that is a pain in the arse to debug :/
That is my only concern -- making insane code crash hard is good, making
it silently mostly work but cause random weirdness is not.
> It actually makes a lot of sense even for the non rust case to avoid
> local_irq_save/restore. We discussed that for years and I surely have
> some half finished patch set to implement it somewhere in the poison
> cabinet.
Heh, yeah, me too. I even have patches using CR8 *somewhere*.
Powered by blists - more mailing lists