Reading a MMIO register Reading memory mapped from user space Reading kernel memory initialized outside the Rust AM By external memory, we mean memory that is manipulated outside the Rust abstract machine. The issue has come up at least a few times in the list: iov_iter dma

RFC #3437 Link to RFC The following work summary is extracted and predicted from the RFC text. The items are ordered by descending priority and potential for a quick prototype Syntactical support from rustc_ast, rustc_hir and rustc_ast_lowering[ ] Change the parser rule to try the path NV first Name resolution rustc_resolve needs a new phase in the late resolver, because it needs to wait for SupertraitItem to register before it can resolve type SubtraitItem = Vec<Self::SupertraitItem>.

Ideas office hours zulip stream ping groups (zulip & mailing list) maintainer entries for documentation, mailing list & keyword "subteam" principles A subteam is an extension of Rust maintainers on a particular topic/subject, the subject is across kernel subsystems, e.g. unsafe code, type design, macro, etc. A subteam generally should maintain documentation or tools regarding the corresponding subject owned by it. The maintainship of such items establish the expertise and the ownership of the subteam. Compared to usual subsystem maintainer groups, the scope of "subteam" is usually across muliptle subsystems, but leave the subsystem-specific decision-making up to the subsystem maintainers.

Critical Status Reports Discussion Questions DMA mask accessors Link: https://lore.kernel.org/lkml/DB6YTN5P23X3.2S0NH4YECP1CP@kernel.org/ rust/kernel/dma.rs

AST enhancement We currently do not distinguish proprer supertrait relation from other bounds. Bounds from trait Subtrait : Supertraits... are mixed into those from where Self: ..., T: Others..., ... ast::GenericBound is already a widely used rustc API, even in external tools. I would preferrably add a new data field to it flag those bounds. Resolution phase The most meaningful resolution happens in the late resolution. Most of the checks and resolution "update", when supertrait is concerned, happens in fn check_trait_item from rustc_resolve/src/late.rs. The complete list of late resolution actions is the following.

Critical Status Reports Discussion Questions LTO Andreas would want to drop his LTO patches and use Gary's series. Checking blockers on Gary's helper LTO series

Problem statement We have a huge repository of atomic operations backed by inline assembly code which resides in the vanilla C side. It is constructed with an elaborate macro infrastructure that has evolved over several years into various flavours of API or code expansion. Today, the kernel crate invokes the atomic operations by materialising the macros and static inlines in rust/helpers, so that the kernel crate can link into. Unfortunately this also comes with a foreseeable and observable comparative disadvantage in performance. One possible solution that has been floating around is to translate the inline assembly blocks, through compiler infrastructure, into Rust inline assembly, so that kernel crate can "inline" the atomics for a performance boost. This document is a proposal to realise the pre-requisites of this experiment and performance benchmarking on the Rust kernel modules. Design principles I would propose the following guidelines in search of solutions.

So far the major items are: Performance evaluation of the changes, with these requirements:Support the same number of NMI nesting level we have now. Overflow detection for irq disable nest levels One major impact is that hardware access vs per-CPU memory access at each time we disable/enable irq.Maybe we can use refscale (kernel/rcu/refscale.c) as a skeletion for micro-benchmarking? Plan/tool/work of avoiding introduction of another irq disable/enable primitives. So what we have current is:local_irq_disable() and local_irq_enable() local_irq_save() and local_irq_restore()

RfL context This enables us to move type Target from trait Deref into trait Receiver without breaking existing impl Deref blocks in Rust ecosystem. Motivation This RFC concerns itself with enabling subtrait impl blocks to supply associated items from one or several supertraits. This RFC proposes an extension so that subtrait impl blocks may designate the associated types from supertraits so that the respective supertraits impl can be implied by collecting the required associated items, without resorting to individual, separate impl-supertrait blocks. Guide-level description Supertraits

This survey only concerns header files that are involved in atomic operations. commit ae8b3a83fb9de394f609035041cd7a668fda2ab3 Headers of interest arch/arm64/include/asm/atomic.h which includesarch/arm64/include/asm/cmpxchg.h arch/arm64/include/asm/lse.h arch/arm64/include/asm/atomic-ll-sc.h arch/arm64/include/asm/barrier.h

Critical Status Reports Discussion Questions Miscellaneous Vitaly gives short presentation of his Rust zblock implementation (20 min max)

Critical Status Reports Discussion Questions 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:

Critical Status Reports Discussion Questions change <Arc<T> as ForeignOwnable>::PointedTo to TRegarding PointedTo: https://lore.kernel.org/rust-for-linux/20240309235927.168915-3-mcanal@igalia.com/ atomic patchset needs some reviews.

Critical Status Reports Discussion Questions Miscellaneous Tooling in distributions Andreas: In the Rust plenary session at LSF, some people complained about tooling in distributions. I promised to check what we think should be working.

Critical Status Reports Discussion Questions SANITY Comments Danilo suggested to have SANITY comments similar to SAFETY comments: https://lore.kernel.org/all/Z9hGcClQXpEYUYZp@cassiopeiae/ A couple points from me:

use std::ptr::NonNull; use std::ops::Deref; struct ARef(NonNull<Device>); impl Deref for ARef { type Target = Device; fn deref(&self) -> &Self::Target { unsafe { self.0.as_ref() }

Critical If we keep having 15ish people each time we meet, we should go back to requiring propose topics ahead of the meeting.[ ] Boqun to follow up if there is a to create the meeting note automatically. Status Reports moudle_param needs review tags for "Subject: [PATCH v8 6/7] rust: add parameter support to the module! macro" https://lore.kernel.org/all/20250227-module-params-v3-v8-6-ceeee85d9347@kernel.org/ Discussion Questions

Critical hrtimer and configfs need reviews. Status Reports Discussion Questions Miscellaneous

Critical Status Reports Discussion Questions Opaque type and Aliased type https://lore.kernel.org/rust-for-linux/CANiq72=o1ouGc4ScvDkz_uMnEfM+D47YQTMh0jTC=Go4tvQvkg@mail.gmail.com/ https://lore.kernel.org/rust-for-linux/20250122055347.597798-1-dirk.behme@de.bosch.com/