[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250528091023.GY39944@noisy.programming.kicks-ass.net>
Date: Wed, 28 May 2025 11:10:23 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Lyude Paul <lyude@...hat.com>
Cc: rust-for-linux@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org,
Daniel Almeida <daniel.almeida@...labora.com>,
Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Valentin Schneider <vschneid@...hat.com>,
Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <lossin@...nel.org>,
Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>,
David Woodhouse <dwmw@...zon.co.uk>, Jens Axboe <axboe@...nel.dk>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
NeilBrown <neilb@...e.de>,
Caleb Sander Mateos <csander@...estorage.com>,
Ryo Takakura <ryotkkr98@...il.com>,
K Prateek Nayak <kprateek.nayak@....com>
Subject: Re: [RFC RESEND v10 03/14] irq & spin_lock: Add counted interrupt
disabling/enabling
On Tue, May 27, 2025 at 06:21:44PM -0400, Lyude Paul wrote:
> From: Boqun Feng <boqun.feng@...il.com>
>
> Currently the nested interrupt disabling and enabling is present by
> _irqsave() and _irqrestore() APIs, which are relatively unsafe, for
> example:
>
> <interrupts are enabled as beginning>
> spin_lock_irqsave(l1, flag1);
> spin_lock_irqsave(l2, flag2);
> spin_unlock_irqrestore(l1, flags1);
> <l2 is still held but interrupts are enabled>
> // accesses to interrupt-disable protect data will cause races.
>
> This is even easier to triggered with guard facilities:
>
> unsigned long flag2;
>
> scoped_guard(spin_lock_irqsave, l1) {
> spin_lock_irqsave(l2, flag2);
> }
> // l2 locked but interrupts are enabled.
> spin_unlock_irqrestore(l2, flag2);
>
> (Hand-to-hand locking critical sections are not uncommon for a
> fine-grained lock design)
>
> And because this unsafety, Rust cannot easily wrap the
> interrupt-disabling locks in a safe API, which complicates the design.
>
> To resolve this, introduce a new set of interrupt disabling APIs:
>
> * local_interrupt_disable();
> * local_interrupt_enable();
>
> They work like local_irq_save() and local_irq_restore() except that 1)
> the outermost local_interrupt_disable() call save the interrupt state
> into a percpu variable, so that the outermost local_interrupt_enable()
> can restore the state, and 2) a percpu counter is added to record the
> nest level of these calls, so that interrupts are not accidentally
> enabled inside the outermost critical section.
>
> Also add the corresponding spin_lock primitives: spin_lock_irq_disable()
> and spin_unlock_irq_enable(), as a result, code as follow:
>
> spin_lock_irq_disable(l1);
> spin_lock_irq_disable(l2);
> spin_unlock_irq_enable(l1);
> // Interrupts are still disabled.
> spin_unlock_irq_enable(l2);
>
> doesn't have the issue that interrupts are accidentally enabled.
>
> This also makes the wrapper of interrupt-disabling locks on Rust easier
> to design.
>
> Signed-off-by: Boqun Feng <boqun.feng@...il.com>
>
> ---
> V10:
> * Add missing __raw_spin_lock_irq_disable() definition in spinlock.c
>
> Signed-off-by: Lyude Paul <lyude@...hat.com>
Your SOB is placed wrong, should be below Boqun's. This way it gets
lost.
Also, is there effort planned to fully remove the save/restore variant?
As before, my main objection is adding variants with overlapping
functionality while not cleaning up the pre-existing code.
Powered by blists - more mailing lists