Re: [PATCH v10 00/10] Fix missing fops.owner in Rust DRM/misc abstractions

Re: [PATCH v10 00/10] Fix missing fops.owner in Rust DRM/misc abstractions

[Miguel Ojeda]

On Tue, Aug 11, 2026 at 8:41 AM Alvin Sun <alvin.sun@linux.dev> wrote:
>
> The series moves `THIS_MODULE` into the `ModuleMetadata` as a const, threads it
> through `#[vtable]` to set `fops.owner` in DRM/miscdevice, and updates configfs
> and rnull to use `this_module::<LocalModule>()`.

Applied to `rust-next` -- thanks everyone!

    [ Fixed `clippy::undocumented_unsafe_blocks` lint by wrapping with
      a block. Added interim `#[allow(dead_code)]`. - Miguel ]

    [ Fixed `rusttest` by adding a dummy `LocalModule`. Removed interim
      `#[allow(dead_code)]`. - Miguel ]

    [ Rebased to avoid the imports cleanup patch. - Miguel ]

    [ Removed Acked-by and Cc. - Miguel ]

By the way, I removed the Acked-by in that last patch since I think it
came from an older version as a series-tag that didn't have the patch.
Please let me know if I should re-add it.

And since I was editing that commit for that reason, I took the chance
to remove the Cc because Petr already gave the Acked-by which you
collected, so normally you don't need to keep both in that case.

I hope that clarifies! :)

Cheers,
Miguel

Re: [PATCH v10 00/10] Fix missing fops.owner in Rust DRM/misc abstractions

[Danilo Krummrich]

(Cc: Mark)

On Wed Aug 12, 2026 at 6:33 PM CEST, Miguel Ojeda wrote:
> On Tue, Aug 11, 2026 at 8:41 AM Alvin Sun <alvin.sun@linux.dev> wrote:
>>
>> The series moves `THIS_MODULE` into the `ModuleMetadata` as a const, threads it
>> through `#[vtable]` to set `fops.owner` in DRM/miscdevice, and updates configfs
>> and rnull to use `this_module::<LocalModule>()`.
>
> Applied to `rust-next` -- thanks everyone!

This series has a semantic conflict with both the driver-core and the drm-rust
tree:

@Mark: When you merge driver-core-next after rust-next (which I think is the
case) then you need to include the diff in [1] into the merge.

In drm-rust-next the build fails with:

	error[E0425]: cannot find type `LocalModule` in the crate root
	   --> rust/kernel/drm/gem/shmem.rs:628:5
	    |
	628 |     #[vtable]
	    |     ^^^^^^^^^ not found in the crate root
	    |
	    = note: this error originates in the attribute macro `vtable` (in Nightly builds, run with -Z macro-backtrace for more info)

which is because the kunit test in rust/kernel/drm/gem/shmem.rs uses the
#[vtable] macro.

This should be fixed up with a patch on top of this series in rust-next.

I came up with to potential solutions [2] and [3]. I think with the new build
system we want [3], but I'm not entirely sure this works correctly with the
current build system in all cases (at least it did survive my tests).

Alternatively, we could just open-code a dummy module as in [2] for now.

[1] driver-core-next merge fixup

diff --git a/rust/kernel/serdev.rs b/rust/kernel/serdev.rs
index a4927452016e..17ca504b7f8d 100644
--- a/rust/kernel/serdev.rs
+++ b/rust/kernel/serdev.rs
@@ -87,7 +87,7 @@ unsafe fn register(
         }

         // SAFETY: `sdrv` is guaranteed to be a valid `DriverType`.
-        to_result(unsafe { bindings::__serdev_device_driver_register(sdrv.get(), module.0) })
+        to_result(unsafe { bindings::__serdev_device_driver_register(sdrv.get(), module.as_ptr()) })
     }

     unsafe fn unregister(sdrv: &Opaque<Self::DriverType>) {

[2] Open-coded dummy module

diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index c04e6c5aa7e0..274924cfcc05 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -157,6 +157,15 @@
 /// Prefix to appear before log messages printed from within the `kernel` crate.
 const __LOG_PREFIX: &[u8] = b"rust_kernel\0";

+/// Dummy module type for `#[vtable]` impl blocks within the kernel crate (e.g. kunit tests).
+struct LocalModule;
+
+impl ModuleMetadata for LocalModule {
+    const NAME: &'static str::CStr = c"rust_kernel";
+    // SAFETY: `try_module_get`/`module_put` handle null module pointers gracefully.
+    const THIS_MODULE: ThisModule = unsafe { ThisModule::from_ptr(core::ptr::null_mut()) };
+}
+
 #[cfg(not(testlib))]
 #[panic_handler]
 fn panic(info: &core::panic::PanicInfo<'_>) -> ! {

[3] Allow module!() for kernel crate

diff --git a/rust/Makefile b/rust/Makefile
index 48adcd9b7851..4f6bf1b4d194 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -279,6 +279,7 @@ rustdoc-pin_init: $(src)/pin-init/src/lib.rs rustdoc-pin_init_internal \
        +$(call if_changed,rustdoc)

 rustdoc-kernel: private is-kernel-object := y
+rustdoc-kernel: private rustc_target_envs = RUST_MODFILE=kernel/lib.rs
 rustdoc-kernel: private rustc_target_flags = --extern ffi --extern pin_init \
     --extern build_error --extern macros \
     --extern bindings --extern uapi \
@@ -351,6 +352,7 @@ rusttestlib-pin_init: $(src)/pin-init/src/lib.rs rusttestlib-macros \
     rusttestlib-pin_init_internal $(obj)/$(libpin_init_internal_name) FORCE
        +$(call if_changed,rustc_test_library)

+rusttestlib-kernel: private rustc_target_envs = RUST_MODFILE=kernel/lib.rs
 rusttestlib-kernel: private rustc_target_flags = --extern ffi \
     --extern build_error --extern macros --extern pin_init \
     --extern bindings --extern uapi \
@@ -386,6 +388,7 @@ quiet_cmd_rustdoc_test_kernel = RUSTDOC TK $<
        rm -rf $(objtree)/$(obj)/test/doctests/kernel; \
        mkdir -p $(objtree)/$(obj)/test/doctests/kernel; \
        $(rustc_target_envs) \
+       RUST_MODFILE=kernel/lib.rs \
        OBJTREE=$(abspath $(objtree)) \
        $(RUSTDOC) --test $(filter-out --remap-path-scope=%,$(rust_flags)) \
                -L$(objtree)/$(obj) --extern ffi --extern pin_init \
@@ -788,6 +791,7 @@ $(obj)/uapi.o: $(src)/uapi/lib.rs \
     $(obj)/uapi/uapi_generated.rs FORCE
        +$(call if_changed_rule,rustc_library)

+$(obj)/kernel.o: private rustc_target_envs = RUST_MODFILE=kernel/lib.rs
 $(obj)/kernel.o: private rustc_target_flags = --extern ffi --extern pin_init \
     --extern build_error --extern macros --extern bindings --extern uapi \
     --extern zerocopy --extern zerocopy_derive
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index c04e6c5aa7e0..7df9159788ad 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -154,8 +154,21 @@
 };
 pub use uapi;

-/// Prefix to appear before log messages printed from within the `kernel` crate.
-const __LOG_PREFIX: &[u8] = b"rust_kernel\0";
+struct KernelCrateModule;
+
+impl Module for KernelCrateModule {
+    fn init(_module: &'static ThisModule) -> error::Result<Self> {
+        Ok(Self)
+    }
+}
+
+macros::module! {
+    type: KernelCrateModule,
+    name: "rust_kernel",
+    authors: ["Rust for Linux Contributors"],
+    description: "The kernel crate",
+    license: "GPL",
+}

 #[cfg(not(testlib))]
 #[panic_handler]

Re: [PATCH v10 00/10] Fix missing fops.owner in Rust DRM/misc abstractions

[Gary Guo]

On Wed Aug 12, 2026 at 10:53 PM BST, Danilo Krummrich wrote:
> (Cc: Mark)
>
> On Wed Aug 12, 2026 at 6:33 PM CEST, Miguel Ojeda wrote:
>> On Tue, Aug 11, 2026 at 8:41 AM Alvin Sun <alvin.sun@linux.dev> wrote:
>>>
>>> The series moves `THIS_MODULE` into the `ModuleMetadata` as a const, threads it
>>> through `#[vtable]` to set `fops.owner` in DRM/miscdevice, and updates configfs
>>> and rnull to use `this_module::<LocalModule>()`.
>>
>> Applied to `rust-next` -- thanks everyone!
>
> This series has a semantic conflict with both the driver-core and the drm-rust
> tree:
>
> @Mark: When you merge driver-core-next after rust-next (which I think is the
> case) then you need to include the diff in [1] into the merge.
>
> In drm-rust-next the build fails with:
>
> 	error[E0425]: cannot find type `LocalModule` in the crate root
> 	   --> rust/kernel/drm/gem/shmem.rs:628:5
> 	    |
> 	628 |     #[vtable]
> 	    |     ^^^^^^^^^ not found in the crate root
> 	    |
> 	    = note: this error originates in the attribute macro `vtable` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> which is because the kunit test in rust/kernel/drm/gem/shmem.rs uses the
> #[vtable] macro.
>
> This should be fixed up with a patch on top of this series in rust-next.
>
> I came up with to potential solutions [2] and [3]. I think with the new build
> system we want [3], but I'm not entirely sure this works correctly with the
> current build system in all cases (at least it did survive my tests).
>
> Alternatively, we could just open-code a dummy module as in [2] for now.
>
> [1] driver-core-next merge fixup
>
> diff --git a/rust/kernel/serdev.rs b/rust/kernel/serdev.rs
> index a4927452016e..17ca504b7f8d 100644
> --- a/rust/kernel/serdev.rs
> +++ b/rust/kernel/serdev.rs
> @@ -87,7 +87,7 @@ unsafe fn register(
>          }
>
>          // SAFETY: `sdrv` is guaranteed to be a valid `DriverType`.
> -        to_result(unsafe { bindings::__serdev_device_driver_register(sdrv.get(), module.0) })
> +        to_result(unsafe { bindings::__serdev_device_driver_register(sdrv.get(), module.as_ptr()) })

`module.0` shouldn't be used in the first place, it just happens to be visible
due to the unfortunate placement at crate root.

Perhaps you can update driver-core tree to use `as_ptr()`? It was already there
and not newly introduced in the series.

>      }
>
>      unsafe fn unregister(sdrv: &Opaque<Self::DriverType>) {
>
> [2] Open-coded dummy module
>
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index c04e6c5aa7e0..274924cfcc05 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -157,6 +157,15 @@
>  /// Prefix to appear before log messages printed from within the `kernel` crate.
>  const __LOG_PREFIX: &[u8] = b"rust_kernel\0";
>
> +/// Dummy module type for `#[vtable]` impl blocks within the kernel crate (e.g. kunit tests).
> +struct LocalModule;
> +
> +impl ModuleMetadata for LocalModule {
> +    const NAME: &'static str::CStr = c"rust_kernel";
> +    // SAFETY: `try_module_get`/`module_put` handle null module pointers gracefully.
> +    const THIS_MODULE: ThisModule = unsafe { ThisModule::from_ptr(core::ptr::null_mut()) };
> +}
> +
>  #[cfg(not(testlib))]
>  #[panic_handler]
>  fn panic(info: &core::panic::PanicInfo<'_>) -> ! {

IMO this is the correct way, also consistent with

https://lore.kernel.org/rust-for-linux/20260811-fix-fops-owner-v10-3-7e71776f9dbe@linux.dev/

It might make sense to add this to rust-next.

Best,
Gary

Re: [PATCH v10 00/10] Fix missing fops.owner in Rust DRM/misc abstractions

[Danilo Krummrich]

On Thu Aug 13, 2026 at 1:57 AM CEST, Gary Guo wrote:
> On Wed Aug 12, 2026 at 10:53 PM BST, Danilo Krummrich wrote:
>> (Cc: Mark)
>>
>> On Wed Aug 12, 2026 at 6:33 PM CEST, Miguel Ojeda wrote:
>>> On Tue, Aug 11, 2026 at 8:41 AM Alvin Sun <alvin.sun@linux.dev> wrote:
>>>>
>>>> The series moves `THIS_MODULE` into the `ModuleMetadata` as a const, threads it
>>>> through `#[vtable]` to set `fops.owner` in DRM/miscdevice, and updates configfs
>>>> and rnull to use `this_module::<LocalModule>()`.
>>>
>>> Applied to `rust-next` -- thanks everyone!
>>
>> This series has a semantic conflict with both the driver-core and the drm-rust
>> tree:
>>
>> @Mark: When you merge driver-core-next after rust-next (which I think is the
>> case) then you need to include the diff in [1] into the merge.
>>
>> In drm-rust-next the build fails with:
>>
>> 	error[E0425]: cannot find type `LocalModule` in the crate root
>> 	   --> rust/kernel/drm/gem/shmem.rs:628:5
>> 	    |
>> 	628 |     #[vtable]
>> 	    |     ^^^^^^^^^ not found in the crate root
>> 	    |
>> 	    = note: this error originates in the attribute macro `vtable` (in Nightly builds, run with -Z macro-backtrace for more info)
>>
>> which is because the kunit test in rust/kernel/drm/gem/shmem.rs uses the
>> #[vtable] macro.
>>
>> This should be fixed up with a patch on top of this series in rust-next.
>>
>> I came up with to potential solutions [2] and [3]. I think with the new build
>> system we want [3], but I'm not entirely sure this works correctly with the
>> current build system in all cases (at least it did survive my tests).
>>
>> Alternatively, we could just open-code a dummy module as in [2] for now.
>>
>> [1] driver-core-next merge fixup
>>
>> diff --git a/rust/kernel/serdev.rs b/rust/kernel/serdev.rs
>> index a4927452016e..17ca504b7f8d 100644
>> --- a/rust/kernel/serdev.rs
>> +++ b/rust/kernel/serdev.rs
>> @@ -87,7 +87,7 @@ unsafe fn register(
>>          }
>>
>>          // SAFETY: `sdrv` is guaranteed to be a valid `DriverType`.
>> -        to_result(unsafe { bindings::__serdev_device_driver_register(sdrv.get(), module.0) })
>> +        to_result(unsafe { bindings::__serdev_device_driver_register(sdrv.get(), module.as_ptr()) })
>
> `module.0` shouldn't be used in the first place, it just happens to be visible
> due to the unfortunate placement at crate root.
>
> Perhaps you can update driver-core tree to use `as_ptr()`? It was already there
> and not newly introduced in the series.

Heh, I just remembered that patch 1 of this series did fix this in a couple of
places and assumed that it was introduced in the same patch without looking
further.

In that case I can throw in a patch in the driver-core tree; will send it
tomorrow.

>>      }
>>
>>      unsafe fn unregister(sdrv: &Opaque<Self::DriverType>) {
>>
>> [2] Open-coded dummy module
>>
>> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
>> index c04e6c5aa7e0..274924cfcc05 100644
>> --- a/rust/kernel/lib.rs
>> +++ b/rust/kernel/lib.rs
>> @@ -157,6 +157,15 @@
>>  /// Prefix to appear before log messages printed from within the `kernel` crate.
>>  const __LOG_PREFIX: &[u8] = b"rust_kernel\0";
>>
>> +/// Dummy module type for `#[vtable]` impl blocks within the kernel crate (e.g. kunit tests).
>> +struct LocalModule;
>> +
>> +impl ModuleMetadata for LocalModule {
>> +    const NAME: &'static str::CStr = c"rust_kernel";
>> +    // SAFETY: `try_module_get`/`module_put` handle null module pointers gracefully.
>> +    const THIS_MODULE: ThisModule = unsafe { ThisModule::from_ptr(core::ptr::null_mut()) };
>> +}
>> +
>>  #[cfg(not(testlib))]
>>  #[panic_handler]
>>  fn panic(info: &core::panic::PanicInfo<'_>) -> ! {
>
> IMO this is the correct way, also consistent with
>
> https://lore.kernel.org/rust-for-linux/20260811-fix-fops-owner-v10-3-7e71776f9dbe@linux.dev/
>
> It might make sense to add this to rust-next.

I feel like [3] is the superior solution (just unsure about the build system
implications); once we have the new build system some subsystem crates will be
actual modules, some will be always built-in. So, in general I think we want to
use the module!() macro.