linux-kernel - Re: [POC 0/6] Allow SpinLockIrq to use a normal Guard interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ce05b149-63ca-46c9-8eb3-67ff3dc5b2c5@gmail.com>
Date: Fri, 18 Oct 2024 18:05:55 +0200
From: Dirk Behme <dirk.behme@...il.com>
To: Andreas Hindborg <a.hindborg@...nel.org>,
 Boqun Feng <boqun.feng@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, 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>, Peter Zijlstra <peterz@...radead.org>,
 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 0/6] Allow SpinLockIrq to use a normal Guard interface

On 18.10.24 13:16, Andreas Hindborg wrote:
> Boqun Feng <boqun.feng@...il.com> writes:
> 
>> Hi Thomas,
>>
>> So this series is what I proposed, previously, because the nested
>> interrupt API in C is local_irq_save() and local_irq_restore(), the
>> following Rust code has the problem of enabling interrupt earlier:
>>
>> 	// l1 and l2 are interrupt disabling locks, their guards (i.e.
>> 	// return of lock()) can be used to track interrupt state.
>>
>> 	// interrupts are enabled in the beginning.
>> 	
>> 	let g1 = l1.lock(); // previous interrupt state is enabled.
>> 	let g2 = l2.lock(); // previous interrupt state is disabled.
>>
>> 	drop(g1); // release l1, if we use g1's state, interrupt will be
>> 		  // enabled. But this is obviously wrong. Because g2
>> 		  // can only exist with interrupt disabled.
>>
>> With the new interrupt disable and enable API, instead of a "unsigned
>> long", a percpu variable is used to track the outermost interrupt state
>> and the nested level, so that "drop(g1);" above won't enable interrupts.
>>
>> Although this requires extra cost, but I think it might be worth paying,
>> because this could make Rust's SpinLockIrq simply use a guard interface
>> as SpinLock.
>>
>> Of course, looking for any comments and suggestions.
>>
>> Boqun Feng (3):
>>   irq & spin_lock: Add counted interrupt disabling/enabling
>>   rust: helper: Add spin_{un,}lock_irq_{enable,disable}() helpers
>>   rust: sync: lock: Add `Backend::BackendInContext`
>>
>> Lyude Paul (3):
>>   rust: Introduce interrupt module
>>   rust: sync: Add SpinLockIrq
>>   rust: sync: Introduce lock::Backend::Context
>>
>>  include/linux/irqflags.h          |  32 +++++++++-
>>  include/linux/irqflags_types.h    |   6 ++
>>  include/linux/spinlock.h          |  13 ++++
>>  include/linux/spinlock_api_smp.h  |  29 +++++++++
>>  include/linux/spinlock_rt.h       |  10 +++
>>  kernel/locking/spinlock.c         |  16 +++++
>>  kernel/softirq.c                  |   3 +
>>  rust/helpers/helpers.c            |   1 +
>>  rust/helpers/interrupt.c          |  18 ++++++
>>  rust/helpers/spinlock.c           |  10 +++
>>  rust/kernel/interrupt.rs          |  64 +++++++++++++++++++
>>  rust/kernel/lib.rs                |   1 +
>>  rust/kernel/sync.rs               |   2 +-
>>  rust/kernel/sync/lock.rs          |  33 +++++++++-
>>  rust/kernel/sync/lock/mutex.rs    |   2 +
>>  rust/kernel/sync/lock/spinlock.rs | 103 ++++++++++++++++++++++++++++++
>>  16 files changed, 340 insertions(+), 3 deletions(-)
>>  create mode 100644 rust/helpers/interrupt.c
>>  create mode 100644 rust/kernel/interrupt.rs
> 
> 
> Tested-by: Andreas Hindborg <a.hindborg@...nel.org>

Yes, it seems to work:

Tested-by: Dirk Behme <dirk.behme@...il.com>

I used rust-next minus the alloc patches as base. An addional
try_lock() due to

https://github.com/Rust-for-Linux/linux/commit/f4c2c90bb7b4ae1812dbaca15d9637eecaac2c9f

is needed for that. But thats all I noticed so far :)

Many thanks!

Dirk


> I ran the `hrtimer` examples on top of this, and it seems to work [1].
> 
> Best regards,
> Andreas
> 
> 
> [1] git git://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/linux.git hrtimer-boqun-poc
>