# Meeting 2025-05-28
<!-- Leave your topic starting with ### in the relevant sections below -->

## Critical
<!-- bugs, soundness issues, urgent patches/reviews etc. -->

## Status Reports
<!-- You want to report on something you are working on/request reviews.
Or you want to know the status of something someone else is doing -->

## Discussion Questions
<!-- Anything that requires lengthy discussion/more general questions also fit here -->

### SpinlockIrq

Lyude:
> Hi! This is something I wanted to get added to the meeting agenda for tomorrow's meeting: as some of you know I've been working on a patch series for a while now to add IRQ spinlocks to rust. I think the majority of the work on the rust side is done at this point, but at the moment there's some open issues that honestly I've been having trouble being able to address since they're very much areas of kernel development I'm not at all familiar with, they're both mentioned in the cover letter for thsi patch series:
>
> https://lkml.org/lkml/2025/5/27/1219

https://lore.kernel.org/rust-for-linux/[e-mail]/

> As well, relevant zulip discussion:
>
> [#**General>Spinlocks with IRQs?**](https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Spinlocks.20with.20IRQs.3F/with/500530982)

Boqun: I think the major issue is Peter's request: https://lore.kernel.org/rust-for-linux/[e-mail]/

spin_lock_irq(); spin_unlock_irq();
spin_lock_irqsave(); spin_unlock_irqrestore();

spin_lock_irq_disable(); spin_unlock_irq_enable();

scope(l1) {
    g2 = guard(l2);
}

use(g2);

// (semi-)creative

spin_lock_irq(l1);
spin_lock(l2);
spin_unlock(l1);
spin_unlock_irq(l2);


local_irq_disable();
local_irq_enable();
local_irq_enable();

Lyude: The other issue is the potential performance impact from the overflow checks that would be added in various functions like `__preempt_count_add`. See:

- https://lore.kernel.org/rust-for-linux/ZxrCrlg1XvaTtJ1I@boqun-archlinux/
- https://lore.kernel.org/rust-for-linux/87y12c4428.ffs@tglx/
- https://lore.kernel.org/rust-for-linux/[e-mail]/

### Xiang "report"

#### ASM

<https://hackmd.io/@rust-for-linux-/Bk6cHLsWee>

#### `arbitrary_self_types`

### Applications for field projections in the current kernel

Benno:
* completed an experimental [implementation of field projections using `syn`](https://github.com/Rust-for-Linux/field-projection/tree/new)
* now looking for experimenting inside of the kernel
* however, I wasn't able to find very many use-cases
* I know about the following applications, but they don't seem to be upstream yet:
* `RcuMutex<T>`: Boqun is working on this and we probably *need* FP for this
* pin-projections: we already use pinned values, but interestingly I wasn't able to find structs defining functions with `self: Pin<&mut Self>`.
* Alice: That's because `Pin` doesn't reborrow so we keep using `!Sync` + `&self` as an alternative.
Benno: Interesting, would you mind giving me some pointers? can't you use `.as_mut()`?
Alice: Yes but `.as_mut()` is inconvenient.
Benno: there is no need for reborrowing with the experiment above :)
* `Ptr<'a, T>` (ie a `&'a T`, but without the usual rust guarantees): I wanted to introduce this abstraction at some point, but I didn't find a good user. RBtree does have some pointers, but they all would require a mystical `'self` lifetime.
* Alice: `VolatilePtr<'a, T>` is an example
* Alice: Getting rid of the macros in DMA buffers
* https://rust.docs.kernel.org/kernel/macro.dma_read.html
* Alice: Also `UserPtr<T>` for userspace pointers.
* Boqun: Or we want `UserSlice<T>`?
* Alice: pointers to seqlock memory. Very similar to pointers into rcu.
* `&mut MaybeUninit<T>`: not really seen used with structs
* `&[mut] Untrusted<T>`: not yet upstream (I'm working on it :)
* [something something workqueue?](https://lore.kernel.org/all/[e-mail]/): I don't have the context on this
* `AtomicPtr<T>`: Boqun is working on this, and FP doesn't seem necessary, but still very convenient
* `ListArcField<T>`
* `UserPtr<T>` (?)
* `SeqLock<T>`
* Could also use some help later when drafting a new version of the RFC, as I have had a lot of difficulty with getting the text right

### NUL-terminated filenames

The proposal to add NUL-terminated file names to `Location` was [accepted](https://github.com/rust-lang/libs-team/issues/466#issuecomment-2914476468). Should we drop the attempt to merge `might_sleep_precision`?

Boqun: I feel it actually makes more sense to add might_sleep_precision() as the temporary solution, because we know for sure once we have it, we can remain the `might_sleep()` as the function instead of a macro.

## Miscellaneous
<!-- stuff that does not fit into other categories -->