linux-kernel - Re: [PATCH v6 0/3] rust: Add irq abstraction, SpinLockIrq

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1eaf7f61-4458-4d15-bbe6-7fd2e34723f4@app.fastmail.com>
Date: Wed, 16 Oct 2024 14:31:09 -0700
From: "Boqun Feng" <boqun.feng@...il.com>
To: "Thomas Gleixner" <tglx@...utronix.de>
Cc: "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 Deacon" <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>,
 "Wedson Almeida Filho" <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>,
 "Alice Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>
Subject: Re: [PATCH v6 0/3] rust: Add irq abstraction, SpinLockIrq



On Wed, Oct 16, 2024, at 2:00 PM, Thomas Gleixner wrote:
> On Sun, Oct 13 2024 at 14:43, Boqun Feng wrote:
>> On Sun, Oct 13, 2024 at 09:06:01PM +0200, Thomas Gleixner wrote:
>> But that makes `cv.wait()` not working, because interrtups would be
>> still disabled when schedule() is called.
>>
>> I'm waiting for Lyude's new version (with lock_first(), and
>> unlock_last()) to see how we can resolve this. We may need to redesign
>> `CondVar::wait`.
>
> Thinking more about this. I think there is a more general problem here.
>
> Much of the rust effort today is trying to emulate the existing way how
> the C implementations work.
>
> I think that's fundamentally wrong because a lot of the programming
> patterns in the kernel are fundamentally wrong in C as well. They are
> just proliferated technical debt.
>
> What should be done is to look at it from the rust perspective in the
> first place: How should this stuff be implemented correctly?
>

I totally agree. One of things that can help is handling nested interruption
disabling differently: we can do something similar as preemption disable,
i.e. using a percpu counter to record the level of interrupt disabling,
as a result, SpinLockIrq::lock() just increases the counter and return the
Guard, when the Guard drops the counter decreases. In this way, no matter
what’s the order of Guard dropping, we remain correctly on interrupt disable
states. I can implement a new set of local_irq_*() in this way and let Rust use
this. Thoughts?

Regards,
Boqun

> Then you work from there and go the extra mile to create some creative
> workarounds at the abstraction level instead of trying to mimic the
> existing C nonsense.
>
> Which in turn gives you a way cleaner pattern of implementing stuff in
> rust.
>
> Stop worrying about mostly irrelevant low level details which are not
> relevant to the primary audience of rust adoption. We can worry about
> them when we replace the scheduler and the low level interrupt handling
> code ten years down the road.
>
> Please focus on providing a sane and efficient programming environment
> to get actual stuff (drivers) into the rust domain.
>
> Thanks,
>
>         tglx