* Re: [PATCH v4 4/9] rust: macros: auto-insert OwnerModule in #[vtable]
From: Gary Guo @ 2026-06-23 13:50 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Ira Weiny, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci
In-Reply-To: <20260623-fix-fops-owner-v4-4-0daf5f077d5c@linux.dev>
On Tue Jun 23, 2026 at 7:29 AM BST, Alvin Sun wrote:
> Auto-add `type OwnerModule: ::kernel::ModuleMetadata;` as a required
> associated type on the trait side if not already defined, and
> auto-insert `type OwnerModule = crate::LocalModule;` on the impl side
> if not explicitly provided, eliminating the need to manually declare
> and implement `OwnerModule` in every vtable trait and impl.
>
> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
> Suggested-by: Gary Guo <gary@garyguo.net>
> Link: https://lore.kernel.org/all/DIMMWHUOLPSH.13JFRHDKDQJGO@garyguo.net
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/macros/lib.rs | 6 ++++++
> rust/macros/vtable.rs | 41 ++++++++++++++++++++++++++++++++++++-----
> 2 files changed, 42 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH v4 3/9] rust: doctest: add LocalModule fallback for #[vtable] ThisModule
From: Gary Guo @ 2026-06-23 13:49 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Ira Weiny, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci
In-Reply-To: <20260623-fix-fops-owner-v4-3-0daf5f077d5c@linux.dev>
On Tue Jun 23, 2026 at 7:29 AM BST, Alvin Sun wrote:
> Add a `LocalModule` struct with a null-pointer `ModuleMetadata` impl
> in the doctest harness, so that `crate::LocalModule` (auto-inserted
> by `#[vtable]`) resolves correctly when there is no `module!` macro.
>
> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
> ---
> scripts/rustdoc_test_gen.rs | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/scripts/rustdoc_test_gen.rs b/scripts/rustdoc_test_gen.rs
> index ee76e96b41eea..198af4e446c8c 100644
> --- a/scripts/rustdoc_test_gen.rs
> +++ b/scripts/rustdoc_test_gen.rs
> @@ -239,6 +239,22 @@ macro_rules! assert_eq {{
>
> const __LOG_PREFIX: &[u8] = b"rust_doctests_kernel\0";
>
> +/// Dummy module type for doctest context.
> +struct LocalModule;
> +
> +use kernel::{{
> + str::CStr,
> + ModuleMetadata,
> + ThisModule, //
> +}};
> +use core::ptr::null_mut;
> +
> +impl ModuleMetadata for LocalModule {{
> + const NAME: &'static CStr = c"rust_doctests_kernel";
> + // SAFETY: `try_module_get`/`module_put` handle null module pointers gracefully.
> + const THIS_MODULE: ThisModule = unsafe {{ ThisModule::from_ptr(null_mut()) }};
> +}}
We probably a macro for crates that are built-in or are not the main crate of a
multi-crate module, and this would be able to use that mechanism.
But this looks okay for now.
Reviewed-by: Gary Guo <gary@garyguo.net>
> +
> {rust_tests}
> "#
> )
^ permalink raw reply
* Re: [PATCH v4 2/9] rust: module: add `THIS_MODULE` const to `ModuleMetadata` trait
From: Gary Guo @ 2026-06-23 13:46 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Ira Weiny, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci
In-Reply-To: <20260623-fix-fops-owner-v4-2-0daf5f077d5c@linux.dev>
On Tue Jun 23, 2026 at 7:29 AM BST, Alvin Sun wrote:
> Since `const_refs_to_static` has been stable as of the MSRV bump, a
> `ThisModule` pointer can now be used in const contexts.
>
> Add a `THIS_MODULE` const to the `ModuleMetadata` trait so that modules
> can provide their `ThisModule` pointer in const contexts such as static
> `file_operations`.
>
> Add a `this_module()` helper to retrieve the `THIS_MODULE` pointer of a
> given module type, and update `__init` to use it instead of the
> `THIS_MODULE` static generated by the `module!` macro.
>
> The `static THIS_MODULE` generated by the `module!` macro is retained
> for backwards compatibility with existing users and removed in a later
> patch once all references have been migrated.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
> ---
> rust/kernel/module.rs | 8 ++++++++
> rust/macros/module.rs | 18 +++++++++++++++++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/rust/kernel/module.rs b/rust/kernel/module.rs
> index be242a82e86d2..5aca42f7a33fc 100644
> --- a/rust/kernel/module.rs
> +++ b/rust/kernel/module.rs
> @@ -42,6 +42,14 @@ fn init(module: &'static ThisModule) -> impl pin_init::PinInit<Self, crate::erro
> pub trait ModuleMetadata {
> /// The name of the module as specified in the `module!` macro.
> const NAME: &'static crate::str::CStr;
> +
> + /// The module's `THIS_MODULE` pointer.
> + const THIS_MODULE: ThisModule;
> +}
> +
> +/// Returns a reference to the `THIS_MODULE` of the given module type.
#[inline]
> +pub const fn this_module<M: ModuleMetadata>() -> &'static ThisModule {
> + &M::THIS_MODULE
> }
With the change,
Reviewed-by: Gary Guo <gary@garyguo.net>
>
> /// Equivalent to `THIS_MODULE` in the C API.
> diff --git a/rust/macros/module.rs b/rust/macros/module.rs
> index 06c18e2075083..aa9a618d5d19e 100644
> --- a/rust/macros/module.rs
> +++ b/rust/macros/module.rs
> @@ -519,6 +519,22 @@ pub(crate) fn module(info: ModuleInfo) -> Result<TokenStream> {
>
> impl ::kernel::ModuleMetadata for #type_ {
> const NAME: &'static ::kernel::str::CStr = #name_cstr;
> +
> + #[cfg(MODULE)]
> + const THIS_MODULE: ::kernel::ThisModule = {
> + extern "C" {
> + static __this_module: ::kernel::types::Opaque<::kernel::bindings::module>;
> + }
> +
> + // SAFETY: `__this_module` is constructed by the kernel at load time
> + // and lives until the module is unloaded.
> + unsafe { ::kernel::ThisModule::from_ptr(__this_module.get()) }
> + };
> +
> + #[cfg(not(MODULE))]
> + const THIS_MODULE: ::kernel::ThisModule = unsafe {
> + ::kernel::ThisModule::from_ptr(::core::ptr::null_mut())
> + };
> }
>
> // Double nested modules, since then nobody can access the public items inside.
> @@ -616,7 +632,7 @@ pub extern "C" fn #ident_exit() {
> /// This function must only be called once.
> unsafe fn __init() -> ::kernel::ffi::c_int {
> let initer = <super::super::LocalModule as ::kernel::InPlaceModule>::init(
> - &super::super::THIS_MODULE
> + ::kernel::module::this_module::<super::super::LocalModule>()
> );
> // SAFETY: No data race, since `__MOD` can only be accessed by this module
> // and there only `__init` and `__exit` access it. These functions are only
^ permalink raw reply
* Re: [PATCH v3 1/7] rust: types: rename ForLt to CovariantForLt
From: Alexandre Courbot @ 2026-06-23 13:32 UTC (permalink / raw)
To: Danilo Krummrich
Cc: gregkh, rafael, ojeda, boqun, gary, bjorn3_gh, lossin, a.hindborg,
aliceryhl, tmgross, ecourtney, m.wilczynski, david.m.ertman,
ira.weiny, leon, daniel.almeida, bhelgaas, kwilczynski,
driver-core, linux-kernel, nova-gpu, dri-devel, linux-pwm,
rust-for-linux
In-Reply-To: <20260618230834.812007-2-dakr@kernel.org>
On Fri Jun 19, 2026 at 8:08 AM JST, Danilo Krummrich wrote:
> Rename ForLt to CovariantForLt to prepare for the introduction of a new
> ForLt base trait that does not require covariance.
>
> The existing ForLt trait requires covariance, which enables the safe
> cast_ref() method. This rename preserves the same semantics under a more
> precise name, making room for a weaker ForLt trait in a subsequent
> commit.
>
> No functional change.
>
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
With the Sashiko comment addressed,
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
(I am also looking at the rest of the series, as well as its DRM
follow-up, but need to let my brain soak into them some more to grok all
the details)
^ permalink raw reply
* Re: [PATCH v17 02/10] rust: types: Add Ownable/Owned types
From: Andreas Hindborg @ 2026-06-23 13:09 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Daniel Almeida, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Bjorn Helgaas,
Krzysztof Wilczyński, Boqun Feng, Uladzislau Rezki,
Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett, Igor Korotin,
Pavel Tikhomirov, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, driver-core, Asahi Lina, Oliver Mangold
In-Reply-To: <ajE5c-5gZtJRoadx@google.com>
Alice Ryhl <aliceryhl@google.com> writes:
> On Thu, Jun 04, 2026 at 10:11:14PM +0200, Andreas Hindborg wrote:
>> From: Asahi Lina <lina+kernel@asahilina.net>
>>
>> By analogy to `AlwaysRefCounted` and `ARef`, an `Ownable` type is a
>> (typically C FFI) type that *may* be owned by Rust, but need not be. Unlike
>> `AlwaysRefCounted`, this mechanism expects the reference to be unique
>> within Rust, and does not allow cloning.
>>
>> Conceptually, this is similar to a `KBox<T>`, except that it delegates
>> resource management to the `T` instead of using a generic allocator.
>>
>> [ om:
>> - Split code into separate file and `pub use` it from types.rs.
>> - Make from_raw() and into_raw() public.
>> - Remove OwnableMut, and make DerefMut dependent on Unpin instead.
>> - Usage example/doctest for Ownable/Owned.
>> - Fixes to documentation and commit message.
>> ]
>>
>> Link: https://lore.kernel.org/all/20250202-rust-page-v1-1-e3170d7fe55e@asahilina.net/
>> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
>> Co-developed-by: Oliver Mangold <oliver.mangold@pm.me>
>> Signed-off-by: Oliver Mangold <oliver.mangold@pm.me>
>> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
>> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
>> [ Andreas: Updated documentation, examples, and formatting. Change safety
>> requirements, safety comments. Use a reference for `release`. ]
>> Reviewed-by: Gary Guo <gary@garyguo.net>
>> Co-developed-by: Andreas Hindborg <a.hindborg@kernel.org>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>
> Overall looks good to me, but two nits below. With them fixed:
>
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
>
>> +pub trait Ownable {
>> + /// Tear down this `Ownable`.
>> + ///
>> + /// Implementers of `Ownable` can use this function to clean up the use of `Self`. This can
>> + /// include freeing the underlying object.
>> + ///
>> + /// # Safety
>> + ///
>> + /// Callers must ensure that the caller has exclusive ownership of `T`, and this ownership can
>> + /// be transferred to the `release` method.
>> + unsafe fn release(&mut self);
>
> I'd make this take a raw pointer because the pointer can be freed during
> the execution of release(), which references don't allow.
Ok.
>
>> diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
>> index 4329d3c2c2e5..4aec7b699269 100644
>> --- a/rust/kernel/types.rs
>> +++ b/rust/kernel/types.rs
>> @@ -11,6 +11,17 @@
>> };
>> use pin_init::{PinInit, Wrapper, Zeroable};
>>
>> +pub use crate::{
>> + owned::{
>> + Ownable,
>> + Owned, //
>> + },
>> + sync::aref::{
>> + ARef,
>> + AlwaysRefCounted, //
>> + }, //
>> +};
>
> We removed the types::ARef re-export, so you shouldn't add it back.
Looks like a rebase failure, I will remove it.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v17 05/10] rust: page: convert to `Ownable`
From: Andreas Hindborg @ 2026-06-23 13:11 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Daniel Almeida, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Bjorn Helgaas,
Krzysztof Wilczyński, Boqun Feng, Uladzislau Rezki,
Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett, Igor Korotin,
Pavel Tikhomirov, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, driver-core, Asahi Lina
In-Reply-To: <CAH5fLgggdf0CM0o4Oa1VbY+y8gQxrU0VU5z_yB4GWCxnbqsFuQ@mail.gmail.com>
Alice Ryhl <aliceryhl@google.com> writes:
> On Thu, Jun 4, 2026 at 10:14 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> From: Asahi Lina <lina@asahilina.net>
>>
>> This allows Page references to be returned as borrowed references,
>> without necessarily owning the struct page.
>>
>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>> [ Andreas: Fix formatting and add a safety comment. ]
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>
> This will not compile unless Rust Binder is also updated.
I'll be sure to build test against binder.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v17 05/10] rust: page: convert to `Ownable`
From: Andreas Hindborg @ 2026-06-23 13:12 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Daniel Almeida, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Bjorn Helgaas,
Krzysztof Wilczyński, Boqun Feng, Uladzislau Rezki,
Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett, Igor Korotin,
Pavel Tikhomirov, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, driver-core, Asahi Lina
In-Reply-To: <ajKGv5ioLSassmND@google.com>
Alice Ryhl <aliceryhl@google.com> writes:
> On Thu, Jun 04, 2026 at 10:11:17PM +0200, Andreas Hindborg wrote:
>> From: Asahi Lina <lina@asahilina.net>
>>
>> This allows Page references to be returned as borrowed references,
>> without necessarily owning the struct page.
>>
>> Signed-off-by: Asahi Lina <lina@asahilina.net>
>> [ Andreas: Fix formatting and add a safety comment. ]
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>> ---
>> rust/kernel/page.rs | 38 +++++++++++++++++++++++++-------------
>> 1 file changed, 25 insertions(+), 13 deletions(-)
>>
>> diff --git a/rust/kernel/page.rs b/rust/kernel/page.rs
>> index 3bdcee0e16a8..844c75e54134 100644
>> --- a/rust/kernel/page.rs
>> +++ b/rust/kernel/page.rs
>> @@ -10,6 +10,11 @@
>> bindings,
>> error::code::*,
>> error::Result,
>> + types::{
>> + Opaque,
>> + Ownable,
>> + Owned, //
>> + },
>> uaccess::UserSliceReader, //
>> };
>> use core::{
>> @@ -105,7 +110,7 @@ pub const fn page_align(addr: usize) -> Option<usize> {
>> ///
>> /// [`VBox`]: kernel::alloc::VBox
>> /// [`Vmalloc`]: kernel::alloc::allocator::Vmalloc
>> -pub struct BorrowedPage<'a>(ManuallyDrop<Page>, PhantomData<&'a Page>);
>> +pub struct BorrowedPage<'a>(ManuallyDrop<NonNull<Page>>, PhantomData<&'a Page>);
>
> BorrowedPage<'a> is no longer needed because it's just &Page.
I'll add some cleaning then.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v17 03/10] rust: implement `ForeignOwnable` for `Owned`
From: Andreas Hindborg @ 2026-06-23 13:10 UTC (permalink / raw)
To: Gary Guo, Miguel Ojeda, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Greg Kroah-Hartman, Dave Ertman, Ira Weiny, Leon Romanovsky,
Paul Moore, Serge Hallyn, Rafael J. Wysocki, David Airlie,
Simona Vetter, Alexander Viro, Christian Brauner, Jan Kara,
Daniel Almeida, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Bjorn Helgaas, Krzysztof Wilczyński, Boqun Feng,
Uladzislau Rezki, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Igor Korotin, Pavel Tikhomirov
Cc: linux-kernel, rust-for-linux, linux-block, linux-security-module,
dri-devel, linux-fsdevel, linux-mm, linux-pm, linux-pci,
driver-core
In-Reply-To: <DJAGDGPKZ4HX.M47NMAU53PCJ@garyguo.net>
"Gary Guo" <gary@garyguo.net> writes:
> On Thu Jun 4, 2026 at 9:11 PM BST, Andreas Hindborg wrote:
>> Implement `ForeignOwnable` for `Owned<T>`. This allows use of `Owned<T>` in
>> places such as the `XArray`.
>>
>> Note that `T` does not need to implement `ForeignOwnable` for `Owned<T>` to
>> implement `ForeignOwnable`.
>>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>> ---
>> rust/kernel/owned.rs | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>>
>> diff --git a/rust/kernel/owned.rs b/rust/kernel/owned.rs
>> index 456e239e906e..5eacdf327d12 100644
>> --- a/rust/kernel/owned.rs
>> +++ b/rust/kernel/owned.rs
>> @@ -15,6 +15,8 @@
>> ptr::NonNull, //
>> };
>>
>> +use kernel::types::ForeignOwnable;
>> +
>> /// Types that specify their own way of performing allocation and destruction. Typically, this trait
>> /// is implemented on types from the C side.
>> ///
>> @@ -108,6 +110,7 @@ pub trait Ownable {
>> ///
>> /// - Until `T::release` is called, this `Owned<T>` exclusively owns the underlying `T`.
>> /// - The `T` value is pinned.
>> +#[repr(transparent)]
>
> AFAIT this `#[repr(transparent)]` isn't actually needed.
I'll drop it.
>
>> pub struct Owned<T: Ownable> {
>> ptr: NonNull<T>,
>> }
>> @@ -185,3 +188,46 @@ fn drop(&mut self) {
>> unsafe { T::release(self.ptr.as_mut()) };
>> }
>> }
>> +
>> +// SAFETY: We derive the pointer to `T` from a valid `T`, so the returned
>> +// pointer satisfy alignment requirements of `T`.
>> +unsafe impl<T: Ownable + 'static> ForeignOwnable for Owned<T> {
>
> You should drop the `'static` bound and put where bound on the GAT below
> instead. See how `Box` is doing it.
I will take a look.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH] gpu: nova-core: parse structs via zerocopy
From: Nicolás Antinori @ 2026-06-23 12:50 UTC (permalink / raw)
To: Alistair Popple, Danilo Krummrich
Cc: Alice Ryhl, Miguel Ojeda, Alexandre Courbot, David Airlie,
Shuah Khan, Simona Vetter, Gary Guo, Onur Özkan,
Tamir Duberstein, Trevor Gross, linux-kernel,
linux-kernel-mentees, dri-devel, rust-for-linux, nova-gpu
In-Reply-To: <ajnPpyQcirSDIZTu@nvdebian.thelocal>
On Mon Jun 22, 2026 at 9:23 PM -03, Alistair Popple wrote:
> On 2026-06-23 at 07:02 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
>> On Mon Jun 22, 2026 at 10:26 PM CEST, Nicolás Antinori wrote:
>> > I did my work on rust-next [1] because drm-rust-next does not have the
>> > zerocopy crate present yet [2]. linux-next contains both zerocopy [3]
>> > and the new users of transmute::FromBytes if I am not mistaken (BitToken,
>> > PciRomHeader, and PmuLookupTableEntry), so I can make the changes there.
>>
>> The drm-rust tree is a bit special, as it remains open for contributions even
>> after it has been tagged for inclusion into Linus's (including throughout the
>> merge window). However, all changes staged in drm-rust-next are not going into
>> linux-next until -rc1 is released.
>>
>> IOW, until -rc1 is released this may or may not resolve all conflicts with
>> drm-rust-next. Once -rc1 is released, it is backmerged into drm-rust-next and
>> drm-rust-next is picked up by linux-next again.
>>
>> Usually all of this remains rather transparent to contributors, but you hit the
>> case of using a new feature introduced through another tree before drm-rust-next
>> caught up with Linus's tree (which will happen next Sunday).
>>
>> Before drm-rust-next caught up, this patch can't be applied anyways, so all
>> good.
>>
>> > I am fairly new to kernel development, I apologize for the mix-up.
>>
>> No worries, you did nothing wrong; thanks for the contribution!
>
> Yes sorry if I gave the impression you did something wrong - this also took me
> a moment to untangle as an experienced contributor so perfectly understandable.
> Appreciate your contribution and hope to see more of them in future.
>
> - Alistair
>
>> - Danilo
Thank you both for the clarifications! I'll wait until the backmerge
into drm-rust-next happens, then I'll rebase this patch along with
the new conversions and send a v2.
Regards,
Nicolás
^ permalink raw reply
* Re: [PATCH v4 9/9] rust: macros: remove `THIS_MODULE` static from `module!`
From: Andreas Hindborg @ 2026-06-23 12:28 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Ira Weiny, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci, Alvin Sun
In-Reply-To: <20260623-fix-fops-owner-v4-9-0daf5f077d5c@linux.dev>
Alvin Sun <alvin.sun@linux.dev> writes:
> All users have been migrated to `ModuleMetadata::THIS_MODULE` const or
> `this_module::<LocalModule>()` helper. The `static THIS_MODULE`
> generated by the `module!` macro is no longer referenced anywhere,
> so remove it to avoid having two sources of the same `ThisModule`
> pointer.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v4 2/9] rust: module: add `THIS_MODULE` const to `ModuleMetadata` trait
From: Andreas Hindborg @ 2026-06-23 12:28 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Ira Weiny, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci, Alvin Sun
In-Reply-To: <20260623-fix-fops-owner-v4-2-0daf5f077d5c@linux.dev>
Alvin Sun <alvin.sun@linux.dev> writes:
> Since `const_refs_to_static` has been stable as of the MSRV bump, a
> `ThisModule` pointer can now be used in const contexts.
>
> Add a `THIS_MODULE` const to the `ModuleMetadata` trait so that modules
> can provide their `ThisModule` pointer in const contexts such as static
> `file_operations`.
>
> Add a `this_module()` helper to retrieve the `THIS_MODULE` pointer of a
> given module type, and update `__init` to use it instead of the
> `THIS_MODULE` static generated by the `module!` macro.
>
> The `static THIS_MODULE` generated by the `module!` macro is retained
> for backwards compatibility with existing users and removed in a later
> patch once all references have been migrated.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v2] rust: helpers: move list_lru and task_work helpers out of binder.c
From: Greg KH @ 2026-06-23 11:42 UTC (permalink / raw)
To: Xiaobo Liu
Cc: rust-for-linux, ojeda, miguel.ojeda.sandonis, akpm, david,
qi.zheng, roman.gushchin, muchun.song, boqun, gary, bjorn3_gh,
lossin, a.hindborg, aliceryhl, tmgross, linux-kernel, linux-mm
In-Reply-To: <20260623102431.3577627-1-cppcoffee@gmail.com>
On Tue, Jun 23, 2026 at 06:24:31PM +0800, Xiaobo Liu wrote:
> The helpers in binder.c wrap generic list_lru and task_work inline
> functions and have nothing to do with binder. Move each of them to a
> file named after its own C header:
>
> - list_lru helpers move to list_lru.c,
> - init_task_work moves to task_work.c.
>
> Add the new list_lru.c to the SHRINKER entry in MAINTAINERS, which
> already covers include/linux/list_lru.h.
>
> Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
> ---
> MAINTAINERS | 1 +
> rust/helpers/helpers.c | 3 ++-
> rust/helpers/{binder.c => list_lru.c} | 7 -------
> rust/helpers/task_work.c | 13 +++++++++++++
> 4 files changed, 16 insertions(+), 8 deletions(-)
> rename rust/helpers/{binder.c => list_lru.c} (72%)
> create mode 100644 rust/helpers/task_work.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba45953bb..428992431 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -24590,6 +24590,7 @@ S: Maintained
> F: Documentation/admin-guide/mm/shrinker_debugfs.rst
> F: include/linux/list_lru.h
> F: include/linux/shrinker.h
> +F: rust/helpers/list_lru.c
> F: mm/list_lru.c
> F: mm/shrinker.c
> F: mm/shrinker_debug.c
> diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
> index 998e31052..ea34101b9 100644
> --- a/rust/helpers/helpers.c
> +++ b/rust/helpers/helpers.c
> @@ -43,7 +43,6 @@
> #include "atomic_ext.c"
> #include "auxiliary.c"
> #include "barrier.c"
> -#include "binder.c"
> #include "bitmap.c"
> #include "bitops.c"
> #include "blk.c"
> @@ -69,6 +68,7 @@
> #include "jump_label.c"
> #include "kunit.c"
> #include "list.c"
> +#include "list_lru.c"
> #include "maple_tree.c"
> #include "mm.c"
> #include "mutex.c"
> @@ -93,6 +93,7 @@
> #include "string.c"
> #include "sync.c"
> #include "task.c"
> +#include "task_work.c"
> #include "time.c"
> #include "uaccess.c"
> #include "usb.c"
> diff --git a/rust/helpers/binder.c b/rust/helpers/list_lru.c
> similarity index 72%
> rename from rust/helpers/binder.c
> rename to rust/helpers/list_lru.c
> index a2327f1b3..3b88d1a96 100644
> --- a/rust/helpers/binder.c
> +++ b/rust/helpers/list_lru.c
> @@ -5,7 +5,6 @@
> */
>
> #include <linux/list_lru.h>
> -#include <linux/task_work.h>
>
> __rust_helper unsigned long rust_helper_list_lru_count(struct list_lru *lru)
> {
> @@ -19,9 +18,3 @@ __rust_helper unsigned long rust_helper_list_lru_walk(struct list_lru *lru,
> {
> return list_lru_walk(lru, isolate, cb_arg, nr_to_walk);
> }
> -
> -__rust_helper void rust_helper_init_task_work(struct callback_head *twork,
> - task_work_func_t func)
> -{
> - init_task_work(twork, func);
> -}
> diff --git a/rust/helpers/task_work.c b/rust/helpers/task_work.c
> new file mode 100644
> index 000000000..cb961cd22
> --- /dev/null
> +++ b/rust/helpers/task_work.c
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Copyright (C) 2025 Google LLC.
> + */
> +
> +#include <linux/task_work.h>
> +
> +__rust_helper void rust_helper_init_task_work(struct callback_head *twork,
> + task_work_func_t func)
> +{
> + init_task_work(twork, func);
> +}
> --
> 2.34.1
>
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* Re: [PATCH v2] rust_binder: reject context manager self-transaction
From: Alice Ryhl @ 2026-06-23 11:37 UTC (permalink / raw)
To: Keshav Verma
Cc: Carlos Llamas, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Miguel Ojeda, Boqun Feng, Gary Guo,
linux-kernel, rust-for-linux, stable
In-Reply-To: <20260622145801.344-1-iganschel@gmail.com>
On Mon, Jun 22, 2026 at 08:28:01PM +0530, Keshav Verma wrote:
> Rust binder resolved handle 0 to the context manager node, but it does not
> reject the case where the caller owns the same node.
>
> The C binder driver rejects transactions from the context-manager process
> to handle 0 after resolving the target node. Match that behavior in Rust
> Binder by rejecting handle 0 transactions when the resolved context-manager
> node is owned by the calling process.
>
> This applies to both synchronous and oneway transactions because both paths
> resolve the target through Process::get_transaction_node().
>
> Cc: stable@kernel.org
> Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver")
> Signed-off-by: Keshav Verma <iganschel@gmail.com>
> ---
> Changes in v2:
> - Compare the underlying OS process task instead of Rust Binder `Process` object.
I would prefer to compare the Binder Process object. Rejecting
transactions between different fds owned by the same process doesn't
really have any benefit and makes fuzz testing much harder.
Alice
^ permalink raw reply
* Re: [PATCH v2 1/3] rust: sync: Add abstraction for synchronize_rcu()
From: Danilo Krummrich @ 2026-06-23 11:16 UTC (permalink / raw)
To: Philipp Stanner
Cc: phasta, Miguel Ojeda, Gary Guo, Pedro Falcato, Miguel Ojeda,
Boqun Feng, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Alexander Viro,
Christian Brauner, Jan Kara, Lyude Paul, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Joel Fernandes,
Josh Triplett, Uladzislau Rezki, Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Zqiang, Christian Schrefl,
rust-for-linux, linux-kernel, linux-fsdevel, rcu
In-Reply-To: <b94b2ef73d70652fba062331aa902c8f89034d7f.camel@mailbox.org>
On Tue Jun 23, 2026 at 1:04 PM CEST, Philipp Stanner wrote:
> with a hyper-strict definition (note that I'm unsure whether calling
> synchronize_rcu() in atomic context is actually even defined behavior;
> I think it is. I'm just brainstorming here)
From the Rust side of things this is well defined; please see [1] and [2].
However, given the kernel context, things such as deadlocks have more
consequences than in userspace. Which is why it is still desirable to catch them
(e.g. with tools like klint).
[1] https://doc.rust-lang.org/reference/behavior-considered-undefined.html
[2] https://doc.rust-lang.org/reference/behavior-not-considered-unsafe.html
^ permalink raw reply
* Re: [PATCH v2 1/3] rust: sync: Add abstraction for synchronize_rcu()
From: Philipp Stanner @ 2026-06-23 11:04 UTC (permalink / raw)
To: Miguel Ojeda, phasta, Gary Guo
Cc: Pedro Falcato, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Alexander Viro,
Christian Brauner, Jan Kara, Lyude Paul, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Joel Fernandes,
Josh Triplett, Uladzislau Rezki, Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Zqiang, Christian Schrefl,
rust-for-linux, linux-kernel, linux-fsdevel, rcu
In-Reply-To: <CANiq72knGU+PUCXUATOkA7225++0nvALNByoJa8gaV_EuyHx6g@mail.gmail.com>
On Tue, 2026-06-23 at 12:24 +0200, Miguel Ojeda wrote:
> On Tue, Jun 23, 2026 at 11:49 AM Philipp Stanner <phasta@mailbox.org> wrote:
> >
> > But it would be interesting to know more about how in general Rust's
> > unsafe comments are related to problems beyond UAF issues, and to what
> > degree we want to document context requirements.
>
> I am confused by the UAF there. Did you mean UB?
>
> Rust's `unsafe` is about way more than just use-after-free -- it is
> about all potential undefined behavior.
>
> At the same time, it is not about merely "dangerous" things.
>
> If you cannot possibly cause UB, then it is not in scope. Otherwise,
> it is very much in scope and the safety preconditions/requirements
> need to be clearly documented (`# Safety`) or justified (`//
> SAFETY:`).
>
> Now, sometimes it may not make a lot of sense to duplicate a ton of
> information, so sometimes we lift text to the Rust module docs and
> refer to it; and sometimes it may also make more sense to refer to
> external docs. One way or another, the goal is to document the
> requirements and what is going on as clearly as possible.
Well, commonly, deadlock is not regarded to be UB.
For RCU the question really is to what extend one wants to have it. The
overall robustness requirement here is definitely for the Rust function
rcu::synchronize_rcu(), since the API caller is the one in charge of
the execution context.
If all potential failures one can cause by calling that function at the
wrong place were regarded to be undefined behavior, then a
synchronize_rcu() Rust function would have to be an unsafe function
always, making a wrapper pointless.
Similarly, Rust's drop() implementations might be potentially "unsafe"
with a hyper-strict definition (note that I'm unsure whether calling
synchronize_rcu() in atomic context is actually even defined behavior;
I think it is. I'm just brainstorming here)
I think briefly documenting the context requirement is fine, but from a
consistency and pragmatism perspective I would not make that a formal
safety requirement.
P.
>
> Cheers,
> Miguel
^ permalink raw reply
* Re: [PATCH v2 1/3] rust: sync: Add abstraction for synchronize_rcu()
From: Danilo Krummrich @ 2026-06-23 11:04 UTC (permalink / raw)
To: Philipp Stanner
Cc: phasta, Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Daniel Almeida, Tamir Duberstein, Alexandre Courbot,
Onur Özkan, Alexander Viro, Christian Brauner, Jan Kara,
Lyude Paul, Paul E. McKenney, Frederic Weisbecker,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Uladzislau Rezki,
Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Zqiang,
Christian Schrefl, rust-for-linux, linux-kernel, linux-fsdevel,
rcu
In-Reply-To: <cf185852a6a28287012154c1ba3823614498177e.camel@mailbox.org>
On Tue Jun 23, 2026 at 8:09 AM CEST, Philipp Stanner wrote:
> The reason I wrote "typically" is because my mind had the potential
> future use-case of ours prefetched where we might have to do a
> synchronize_rcu() to wait for a C backend to be done with something,
> where no one really holds a Rust `Guard` (though of course the read
> lock).
In that case I'd just say "read side critical section" and then mention the
rcu::Guard type as one way to end up in such.
In comparison with other synchronization primitives, RCU is a global mechanism,
so only talking about the rcu::Guard specifically might indeed be misleading.
>> Also, while it's implicit, it might still be worth to explicitly call out that
>> this means concurrently held Guard objects (concurrent read side critical
>> sections), i.e. subsequent read side critical sections may still run
>> concurrently.
>
> That's quite generic RCU knowledge IMO. I'm not sure to what degree one
> wants to document RCU in general at this new function here, vs just the
> Rust API.
One or two precise sentences should be enough; no need to document RCU in
general.
> Rewording the documentation is fine by me, but since we're in a nitty
> domain here I would then ask you to provide a few draft sentences that
> would satisfy your basic requirements.
Should be as simple as adding "in progress", e.g. considering the above:
This waits for all RCU read-side critical sections already in progress,
including those established by an [`rcu::Guard`].
This does not prevent new read-side critical sections from starting;
those may begin and run while this call blocks.
^ permalink raw reply
* [PATCH v2] rust: helpers: move list_lru and task_work helpers out of binder.c
From: Xiaobo Liu @ 2026-06-23 10:24 UTC (permalink / raw)
To: rust-for-linux
Cc: ojeda, miguel.ojeda.sandonis, akpm, david, qi.zheng,
roman.gushchin, muchun.song, boqun, gary, bjorn3_gh, lossin,
a.hindborg, aliceryhl, tmgross, linux-kernel, linux-mm,
Xiaobo Liu
In-Reply-To: <CANiq72=sSkApehxg6eEpAoNU8zSsRAfqD+RVymM3UQGuvfKyeQ@mail.gmail.com>
The helpers in binder.c wrap generic list_lru and task_work inline
functions and have nothing to do with binder. Move each of them to a
file named after its own C header:
- list_lru helpers move to list_lru.c,
- init_task_work moves to task_work.c.
Add the new list_lru.c to the SHRINKER entry in MAINTAINERS, which
already covers include/linux/list_lru.h.
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
---
MAINTAINERS | 1 +
rust/helpers/helpers.c | 3 ++-
rust/helpers/{binder.c => list_lru.c} | 7 -------
rust/helpers/task_work.c | 13 +++++++++++++
4 files changed, 16 insertions(+), 8 deletions(-)
rename rust/helpers/{binder.c => list_lru.c} (72%)
create mode 100644 rust/helpers/task_work.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ba45953bb..428992431 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24590,6 +24590,7 @@ S: Maintained
F: Documentation/admin-guide/mm/shrinker_debugfs.rst
F: include/linux/list_lru.h
F: include/linux/shrinker.h
+F: rust/helpers/list_lru.c
F: mm/list_lru.c
F: mm/shrinker.c
F: mm/shrinker_debug.c
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index 998e31052..ea34101b9 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -43,7 +43,6 @@
#include "atomic_ext.c"
#include "auxiliary.c"
#include "barrier.c"
-#include "binder.c"
#include "bitmap.c"
#include "bitops.c"
#include "blk.c"
@@ -69,6 +68,7 @@
#include "jump_label.c"
#include "kunit.c"
#include "list.c"
+#include "list_lru.c"
#include "maple_tree.c"
#include "mm.c"
#include "mutex.c"
@@ -93,6 +93,7 @@
#include "string.c"
#include "sync.c"
#include "task.c"
+#include "task_work.c"
#include "time.c"
#include "uaccess.c"
#include "usb.c"
diff --git a/rust/helpers/binder.c b/rust/helpers/list_lru.c
similarity index 72%
rename from rust/helpers/binder.c
rename to rust/helpers/list_lru.c
index a2327f1b3..3b88d1a96 100644
--- a/rust/helpers/binder.c
+++ b/rust/helpers/list_lru.c
@@ -5,7 +5,6 @@
*/
#include <linux/list_lru.h>
-#include <linux/task_work.h>
__rust_helper unsigned long rust_helper_list_lru_count(struct list_lru *lru)
{
@@ -19,9 +18,3 @@ __rust_helper unsigned long rust_helper_list_lru_walk(struct list_lru *lru,
{
return list_lru_walk(lru, isolate, cb_arg, nr_to_walk);
}
-
-__rust_helper void rust_helper_init_task_work(struct callback_head *twork,
- task_work_func_t func)
-{
- init_task_work(twork, func);
-}
diff --git a/rust/helpers/task_work.c b/rust/helpers/task_work.c
new file mode 100644
index 000000000..cb961cd22
--- /dev/null
+++ b/rust/helpers/task_work.c
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Copyright (C) 2025 Google LLC.
+ */
+
+#include <linux/task_work.h>
+
+__rust_helper void rust_helper_init_task_work(struct callback_head *twork,
+ task_work_func_t func)
+{
+ init_task_work(twork, func);
+}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/3] rust: sync: Add abstraction for synchronize_rcu()
From: Miguel Ojeda @ 2026-06-23 10:24 UTC (permalink / raw)
To: phasta, Gary Guo
Cc: Pedro Falcato, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Alexander Viro,
Christian Brauner, Jan Kara, Lyude Paul, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Joel Fernandes,
Josh Triplett, Uladzislau Rezki, Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Zqiang, Christian Schrefl,
rust-for-linux, linux-kernel, linux-fsdevel, rcu
In-Reply-To: <908762cb7fd90df1df70eda28363a0015c404527.camel@mailbox.org>
On Tue, Jun 23, 2026 at 11:49 AM Philipp Stanner <phasta@mailbox.org> wrote:
>
> But it would be interesting to know more about how in general Rust's
> unsafe comments are related to problems beyond UAF issues, and to what
> degree we want to document context requirements.
I am confused by the UAF there. Did you mean UB?
Rust's `unsafe` is about way more than just use-after-free -- it is
about all potential undefined behavior.
At the same time, it is not about merely "dangerous" things.
If you cannot possibly cause UB, then it is not in scope. Otherwise,
it is very much in scope and the safety preconditions/requirements
need to be clearly documented (`# Safety`) or justified (`//
SAFETY:`).
Now, sometimes it may not make a lot of sense to duplicate a ton of
information, so sometimes we lift text to the Rust module docs and
refer to it; and sometimes it may also make more sense to refer to
external docs. One way or another, the goal is to document the
requirements and what is going on as clearly as possible.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] rust: helpers: move list_lru and task_work helpers out of binder.c
From: Miguel Ojeda @ 2026-06-23 9:52 UTC (permalink / raw)
To: Xiaobo Liu
Cc: rust-for-linux, ojeda, Linux-MM, linux-kernel, Andrew Morton,
Dave Chinner, Qi Zheng, Roman Gushchin, Muchun Song,
Lorenzo Stoakes, Liam R. Howlett, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan
In-Reply-To: <20260623093919.3543473-1-cppcoffee@gmail.com>
On Tue, Jun 23, 2026 at 11:39 AM Xiaobo Liu <cppcoffee@gmail.com> wrote:
>
> The helpers in binder.c wrap generic list_lru and task_work inline
> functions and have nothing to do with binder. Move them to mm.c and
> task_work.c respectively, where they belong by subsystem.
>
> Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
In general, please Cc the relevant maintainers/reviewers/subsystems as
well as the LKML -- `scripts/get_maintainer.pl` can help there;
otherwise, you can check `MAINTAINERS` manually too.
Doing so here for you to give you an idea of how it could look like --
I hope it helps.
> +#include <linux/list_lru.h>
Since you are creating a new file for `task_work`, what about one for
`list_lru` too?
(And we should likely add the new files to the respective
`MAINTAINERS` entries.)
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2 1/3] rust: sync: Add abstraction for synchronize_rcu()
From: Philipp Stanner @ 2026-06-23 9:48 UTC (permalink / raw)
To: Pedro Falcato, Philipp Stanner
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Alexander Viro,
Christian Brauner, Jan Kara, Lyude Paul, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Joel Fernandes,
Josh Triplett, Uladzislau Rezki, Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Zqiang, Christian Schrefl,
rust-for-linux, linux-kernel, linux-fsdevel, rcu
In-Reply-To: <ajpJmjTST-Hoxutb@pedro-suse.lan>
On Tue, 2026-06-23 at 09:56 +0100, Pedro Falcato wrote:
> On Mon, Jun 22, 2026 at 07:32:49PM +0200, Philipp Stanner wrote:
> > synchronize_rcu() is a frequently used C function which is always safe
> > to be called.
> >
> > Add a safe abstraction for synchronize_rcu().
> >
> > Signed-off-by: Philipp Stanner <phasta@kernel.org>
> > ---
> > rust/kernel/sync/rcu.rs | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs
> > index a32bef6e490b..0d438ef31766 100644
> > --- a/rust/kernel/sync/rcu.rs
> > +++ b/rust/kernel/sync/rcu.rs
> > @@ -50,3 +50,12 @@ fn drop(&mut self) {
> > pub fn read_lock() -> Guard {
> > Guard::new()
> > }
> > +
> > +/// Wait for one RCU grace period.
> > +///
> > +/// You typically do this to wait for everyone holding a [`Guard`].
> > +#[inline]
> > +pub fn synchronize_rcu() {
> > + // SAFETY: `synchronize_rcu()` is always safe to be called. It just waits for a grace period.
>
> Commething randomly here (I know as much rust as the next not-knowing-rust-guy, sadly),
> but synchronize_rcu() is not always safe to be called. You cannot call it if
> you have the rcu read lock, or cannot sleep for any reason. I don't know if
> you can encode these in the rust type system though.
Preventing illegal actions in atomic context seems very difficult to
achieve in Rust and AFAIK the only viable path forward currently is to
have klint check for rule violations. Gary is working on that.
But it would be interesting to know more about how in general Rust's
unsafe comments are related to problems beyond UAF issues, and to what
degree we want to document context requirements.
C documents functions like synchronize_rcu() in much detail, but its
documentation trusts on the readers general familiarity with RCU,
assuming no one would come up with the idea of calling
synchronize_rcu() in an atomic context.
P.
^ permalink raw reply
* [PATCH] rust: helpers: move list_lru and task_work helpers out of binder.c
From: Xiaobo Liu @ 2026-06-23 9:39 UTC (permalink / raw)
To: rust-for-linux; +Cc: ojeda, Xiaobo Liu
The helpers in binder.c wrap generic list_lru and task_work inline
functions and have nothing to do with binder. Move them to mm.c and
task_work.c respectively, where they belong by subsystem.
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
---
rust/helpers/binder.c | 27 ---------------------------
rust/helpers/helpers.c | 2 +-
rust/helpers/mm.c | 14 ++++++++++++++
rust/helpers/task_work.c | 9 +++++++++
4 files changed, 24 insertions(+), 28 deletions(-)
delete mode 100644 rust/helpers/binder.c
create mode 100644 rust/helpers/task_work.c
diff --git a/rust/helpers/binder.c b/rust/helpers/binder.c
deleted file mode 100644
index a2327f1b3..000000000
--- a/rust/helpers/binder.c
+++ /dev/null
@@ -1,27 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-/*
- * Copyright (C) 2025 Google LLC.
- */
-
-#include <linux/list_lru.h>
-#include <linux/task_work.h>
-
-__rust_helper unsigned long rust_helper_list_lru_count(struct list_lru *lru)
-{
- return list_lru_count(lru);
-}
-
-__rust_helper unsigned long rust_helper_list_lru_walk(struct list_lru *lru,
- list_lru_walk_cb isolate,
- void *cb_arg,
- unsigned long nr_to_walk)
-{
- return list_lru_walk(lru, isolate, cb_arg, nr_to_walk);
-}
-
-__rust_helper void rust_helper_init_task_work(struct callback_head *twork,
- task_work_func_t func)
-{
- init_task_work(twork, func);
-}
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index 998e31052..fe0883b33 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -43,7 +43,6 @@
#include "atomic_ext.c"
#include "auxiliary.c"
#include "barrier.c"
-#include "binder.c"
#include "bitmap.c"
#include "bitops.c"
#include "blk.c"
@@ -93,6 +92,7 @@
#include "string.c"
#include "sync.c"
#include "task.c"
+#include "task_work.c"
#include "time.c"
#include "uaccess.c"
#include "usb.c"
diff --git a/rust/helpers/mm.c b/rust/helpers/mm.c
index b5540997b..941984feb 100644
--- a/rust/helpers/mm.c
+++ b/rust/helpers/mm.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
+#include <linux/list_lru.h>
#include <linux/mm.h>
#include <linux/sched/mm.h>
@@ -8,6 +9,19 @@ __rust_helper void rust_helper_mmgrab(struct mm_struct *mm)
mmgrab(mm);
}
+__rust_helper unsigned long rust_helper_list_lru_count(struct list_lru *lru)
+{
+ return list_lru_count(lru);
+}
+
+__rust_helper unsigned long rust_helper_list_lru_walk(struct list_lru *lru,
+ list_lru_walk_cb isolate,
+ void *cb_arg,
+ unsigned long nr_to_walk)
+{
+ return list_lru_walk(lru, isolate, cb_arg, nr_to_walk);
+}
+
__rust_helper void rust_helper_mmdrop(struct mm_struct *mm)
{
mmdrop(mm);
diff --git a/rust/helpers/task_work.c b/rust/helpers/task_work.c
new file mode 100644
index 000000000..5bdb752cb
--- /dev/null
+++ b/rust/helpers/task_work.c
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/task_work.h>
+
+__rust_helper void rust_helper_init_task_work(struct callback_head *twork,
+ task_work_func_t func)
+{
+ init_task_work(twork, func);
+}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 7/7] rust: doctest: use vertical import style
From: David Gow @ 2026-06-23 9:19 UTC (permalink / raw)
To: Alvin Sun, Arnd Bergmann, Greg Kroah-Hartman, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Jens Axboe, Brendan Higgins, Rae Moar
Cc: rust-for-linux, linux-block, linux-kselftest, kunit-dev
In-Reply-To: <20260521-miscdev-use-format-v3-7-56240ca70d0c@linux.dev>
Le 21/05/2026 à 2:57 PM, Alvin Sun a écrit :
> Convert `use` imports to vertical layout for better readability and
> maintainability.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
> ---
Assuming this'll go in via the Rust tree, given there are other changers
to the rustdoc work which will likely go in that way. (But, if we'd
prefer it to go in via kselftest/kunit, that shouldn't be a problem.)
Acked-by: David Gow <david@davidgow.net>
Cheers,
-- David
> scripts/rustdoc_test_gen.rs | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/rustdoc_test_gen.rs b/scripts/rustdoc_test_gen.rs
> index d61a77219a8c2..ee76e96b41eea 100644
> --- a/scripts/rustdoc_test_gen.rs
> +++ b/scripts/rustdoc_test_gen.rs
> @@ -31,8 +31,15 @@
> use std::{
> fs,
> fs::File,
> - io::{BufWriter, Read, Write},
> - path::{Path, PathBuf},
> + io::{
> + BufWriter,
> + Read,
> + Write, //
> + },
> + path::{
> + Path,
> + PathBuf, //
> + }, //
> };
>
> /// Find the real path to the original file based on the `file` portion of the test name.
>
^ permalink raw reply
* Re: [PATCH v2 1/3] rust: sync: Add abstraction for synchronize_rcu()
From: Pedro Falcato @ 2026-06-23 8:56 UTC (permalink / raw)
To: Philipp Stanner
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Alexander Viro,
Christian Brauner, Jan Kara, Lyude Paul, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Joel Fernandes,
Josh Triplett, Uladzislau Rezki, Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Zqiang, Christian Schrefl,
rust-for-linux, linux-kernel, linux-fsdevel, rcu
In-Reply-To: <20260622173250.411377-3-phasta@kernel.org>
On Mon, Jun 22, 2026 at 07:32:49PM +0200, Philipp Stanner wrote:
> synchronize_rcu() is a frequently used C function which is always safe
> to be called.
>
> Add a safe abstraction for synchronize_rcu().
>
> Signed-off-by: Philipp Stanner <phasta@kernel.org>
> ---
> rust/kernel/sync/rcu.rs | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs
> index a32bef6e490b..0d438ef31766 100644
> --- a/rust/kernel/sync/rcu.rs
> +++ b/rust/kernel/sync/rcu.rs
> @@ -50,3 +50,12 @@ fn drop(&mut self) {
> pub fn read_lock() -> Guard {
> Guard::new()
> }
> +
> +/// Wait for one RCU grace period.
> +///
> +/// You typically do this to wait for everyone holding a [`Guard`].
> +#[inline]
> +pub fn synchronize_rcu() {
> + // SAFETY: `synchronize_rcu()` is always safe to be called. It just waits for a grace period.
Commething randomly here (I know as much rust as the next not-knowing-rust-guy, sadly),
but synchronize_rcu() is not always safe to be called. You cannot call it if
you have the rcu read lock, or cannot sleep for any reason. I don't know if
you can encode these in the rust type system though.
--
Pedro
^ permalink raw reply
* [PATCH v4 9/9] rust: macros: remove `THIS_MODULE` static from `module!`
From: Alvin Sun @ 2026-06-23 6:29 UTC (permalink / raw)
To: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Ira Weiny, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci, Alvin Sun
In-Reply-To: <20260623-fix-fops-owner-v4-0-0daf5f077d5c@linux.dev>
All users have been migrated to `ModuleMetadata::THIS_MODULE` const or
`this_module::<LocalModule>()` helper. The `static THIS_MODULE`
generated by the `module!` macro is no longer referenced anywhere,
so remove it to avoid having two sources of the same `ThisModule`
pointer.
Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
---
rust/macros/module.rs | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/rust/macros/module.rs b/rust/macros/module.rs
index aa9a618d5d19e..23b6a1b456b80 100644
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@ -497,22 +497,6 @@ pub(crate) fn module(info: ModuleInfo) -> Result<TokenStream> {
/// Used by the printing macros, e.g. [`info!`].
const __LOG_PREFIX: &[u8] = #name_cstr.to_bytes_with_nul();
- // SAFETY: `__this_module` is constructed by the kernel at load time and will not be
- // freed until the module is unloaded.
- #[cfg(MODULE)]
- static THIS_MODULE: ::kernel::ThisModule = unsafe {
- extern "C" {
- static __this_module: ::kernel::types::Opaque<::kernel::bindings::module>;
- };
-
- ::kernel::ThisModule::from_ptr(__this_module.get())
- };
-
- #[cfg(not(MODULE))]
- static THIS_MODULE: ::kernel::ThisModule = unsafe {
- ::kernel::ThisModule::from_ptr(::core::ptr::null_mut())
- };
-
/// The `LocalModule` type is the type of the module created by `module!`,
/// `module_pci_driver!`, `module_platform_driver!`, etc.
type LocalModule = #type_;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 7/9] rust: configfs: use `LocalModule` for `THIS_MODULE`
From: Alvin Sun @ 2026-06-23 6:29 UTC (permalink / raw)
To: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Ira Weiny, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci, Alvin Sun
In-Reply-To: <20260623-fix-fops-owner-v4-0-0daf5f077d5c@linux.dev>
Replace the `THIS_MODULE` static reference in the `configfs_attrs!`
macro with `this_module::<LocalModule>()`, and update
rnull to import `LocalModule` instead of `THIS_MODULE`, consistent
with the move of `THIS_MODULE` into the `ModuleMetadata` trait.
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
---
drivers/block/rnull/configfs.rs | 6 ++----
rust/kernel/configfs.rs | 8 +++++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/block/rnull/configfs.rs b/drivers/block/rnull/configfs.rs
index c10a55fc58948..b2547ad1e5ddd 100644
--- a/drivers/block/rnull/configfs.rs
+++ b/drivers/block/rnull/configfs.rs
@@ -1,9 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
-use super::{
- NullBlkDevice,
- THIS_MODULE, //
-};
+use super::NullBlkDevice;
+use crate::LocalModule;
use kernel::{
block::mq::gen_disk::{
GenDisk,
diff --git a/rust/kernel/configfs.rs b/rust/kernel/configfs.rs
index 2339c6467325d..b542422115461 100644
--- a/rust/kernel/configfs.rs
+++ b/rust/kernel/configfs.rs
@@ -875,7 +875,7 @@ fn as_ptr(&self) -> *const bindings::config_item_type {
/// configfs::Subsystem<Configuration>,
/// Configuration
/// >::new_with_child_ctor::<N,Child>(
-/// &THIS_MODULE,
+/// ::kernel::module::this_module::<LocalModule>(),
/// &CONFIGURATION_ATTRS
/// );
///
@@ -1021,7 +1021,8 @@ macro_rules! configfs_attrs {
static [< $data:upper _TPE >] : $crate::configfs::ItemType<$container, $data> =
$crate::configfs::ItemType::<$container, $data>::new::<N>(
- &THIS_MODULE, &[<$ data:upper _ATTRS >]
+ $crate::module::this_module::<LocalModule>(),
+ &[<$ data:upper _ATTRS >]
);
)?
@@ -1030,7 +1031,8 @@ macro_rules! configfs_attrs {
$crate::configfs::ItemType<$container, $data> =
$crate::configfs::ItemType::<$container, $data>::
new_with_child_ctor::<N, $child>(
- &THIS_MODULE, &[<$ data:upper _ATTRS >]
+ $crate::module::this_module::<LocalModule>(),
+ &[<$ data:upper _ATTRS >]
);
)?
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox