Thread (19 messages) 19 messages, 4 authors, 24d ago

Re: [PATCH v21 9/9] rust: page: add `ExclusivePage` for race-free page access

flat view

From: Matthew Wilcox <willy@infradead.org>
Date: 2026-09-13 03:11:52
Also in: dri-devel, driver-core, linux-block, linux-fsdevel, linux-mm, linux-pci, linux-pm, linux-pwm, linux-usb, lkml, rust-for-linux

On Thu, Sep 10, 2026 at 11:00:13AM +0200, Andreas Hindborg wrote:
`ExclusivePage` wraps a regular page but adds an invariant that the
page data area does not incur data races. This means `ExclusivePage`
cannot be mapped to user space or shared with devices, and it
becomes simpler to directly reference the contents of the page.

Since `Page` implements `AlwaysRefCounted`, handing out a `&Page`
from an `ExclusivePage` would allow safe code to obtain an
`ARef<Page>` to the page and break the aliasing invariant of
`ExclusivePage`. Thus, do not implement `Deref<Target = Page>` for
`ExclusivePage`.
Given this description, I wonder if this shouldn't be implemented by
alloc_frozen_pages() / free_frozen_pages().  We'ree certainly trying
to move the C parts of the kernel away from thinking that pages have a
refcount (folios have a refcount; otheer memdescs may or may not have
a refcount).  Do your intended users of this actually have a need for a
refcount?
quoted hunk ↗ jump to hunk
+++ b/rust/kernel/page.rs
@@ -17,7 +17,11 @@
         AlwaysRefCounted,
         RefCounted, //
     },
-    types::Opaque,
+    types::{
+        Opaque,
+        Ownable,
+        Owned, //
+    },
While I'm asking stupid questions, what's the significance of the //
after Owned?  I see it after RefCounted too.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help