Re: [PATCH v7 3/6] rust: irq: add support for non-threaded IRQs and handlers

["Danilo Krummrich" <dakr@kernel.org>]

On Wed Jul 23, 2025 at 5:44 PM CEST, Alice Ryhl wrote:
> On Wed, Jul 23, 2025 at 05:03:12PM +0200, Danilo Krummrich wrote:
>> On Wed Jul 23, 2025 at 4:56 PM CEST, Daniel Almeida wrote:
>> >> On 23 Jul 2025, at 11:35, Danilo Krummrich <dakr@kernel.org> wrote:
>> >> On 7/23/25 4:26 PM, Boqun Feng wrote:
>> >>> On Wed, Jul 23, 2025 at 10:55:20AM -0300, Daniel Almeida wrote:
>> >>> But sure, this and the handler pinned initializer thing is not a blocker
>> >>> issue. However, I would like to see them resolved as soon as possible
>> >>> once merged.
>> >> 
>> >> I think it would be trivial to make the T an impl PinInit<T, E> and use a
>> >> completion as example instead of an atomic. So, we should do it right away.
>> >> 
>> >> - Danilo
>> >
>> >
>> > I agree that this is a trivial change to make. My point here is not to postpone
>> > the work; I am actually somewhat against switching to completions, as per the
>> > reasoning I provided in my latest reply to Boqun. My plan is to switch directly
>> > to whatever will substitute AtomicU32.
>> 
>> I mean, Boqun has a point. AFAIK, the Rust atomics are UB in the kernel.
>> 
>> So, this is a bit as if we would use spin_lock() instead of spin_lock_irq(),
>> it's just not correct. Hence, we may not want to showcase it until it's actually
>> resolved.
>> 
>> The plain truth is, currently there's no synchronization primitive for getting
>> interior mutability in interrupts.
>
> Is the actual argument here "we are getting rid of Rust atomics in the
> next cycle, so please don't introduce any more users during the next
> cycle because if you do it will take one cycle longer to get rid of
> all Rust atomics"?

That's an argument as well, I guess.

> I can accept that argument. But I don't accept the argument that we
> shouldn't use them here because of the UB technicality. That is an
> isolated demand for rigor and I think it is unreasonable. Using Rust
> atomics is an accepted workaround until the LKMM atomics land.

I think there's a difference between actually needing them and using them to
showcase something. Or in other words, limiting workarounds to only those places
where we can't avoid them seems like the correct thing to do.

Using a completion in the hard IRQ and showing a spinlock or mutex example in
the threaded handler seems like a good mix to me.