On Fri, Mar 21, 2025 at 01:12:30PM +0100, Danilo Krummrich wrote: > Not all device resources are managed in the context of the subsystem, so > subsystem-level revokes do not apply. They could, you could say that these rust APIs are only safe to use for device drivers with C code providing a fence semantic, eg through a subsystem. > For the DMA coherent allocations, please see my comment in [1]. Revoking the > device resources associated with a DMA coherent allocation should hence never > cause any overhead for accessing DMA memory. > [1] https://github.com/Rust-for-Linux/linux/blob/rust-next/rust/kernel/dma.rs#L120 I don't know what to make of this. You argued so much to support revocable for rust ideological reasons and in the end the proposal is to just completely gives up on all of that? Not even an optional runtime check? :( And I'm not sure about the comment written: > // However, it is neither desirable nor necessary to protect the allocated memory of the DMA > // allocation from surviving device unbind; There are alot of things on this path that depend on the struct device, there are two kinds of per-device coherent memory allocators and swiotlb as well. It looks like there are cases where the actual memory must not outlive the driver binding. So, I'd argue that it is necessary, and changing that on the C side looks like a big project. Jason
