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

[Miguel Ojeda]

On Tue, Jul 28, 2026 at 10:39 AM Alvin Sun <alvi...@linux.dev> wrote:
>
> Back in v3, Gary suggested this series go via the rust tree.
> Would you be happy with that, or would you prefer a different
> path? If so, is there anything else needed from my side?

That is fine with me, but let's see what the modules maintainers think...

Luis, Petr, Daniel, Sami: what would you like to do? This touches your
entry, so it would be nice to know what your thoughts are /
Acked-by's.

Thanks!

Cheers,
Miguel

[Miguel Ojeda]

On Thu, Jul 23, 2026 at 4:11 AM Alvin Sun <alvi...@linux.dev> wrote:
>
> base-commit: b7e5ac83cb16f7ffd11dc23736f84276602100ed

Was this old tag used for some reason?

> prerequisite-change-id: 20260519-miscdev-use-format-9ab7e83b1c11:v3
> prerequisite-patch-id: 405b334ff0d48ad350014f05a2321bdbaa025400
> prerequisite-patch-id: 604b631c81d5423f4ebb2e12ba2d22e9ce371bfc
> prerequisite-patch-id: cb550d94cefe01920e0d3ced2b2bcbecd76f3907
> prerequisite-patch-id: 3bc830839742591460cb86d9472c04f4686dc600
> prerequisite-patch-id: 571058244bc8c7088638d2e3225713011246c7e9
> prerequisite-patch-id: 347c5a3c6dbef9832bfce8419fc23e6e08ba477f
> prerequisite-patch-id: 3e202d988b56b88446f7535e90d3f00cf5f15701

Are all these actually needed? Some seem unrelated (some were already
applied too). The only one that seems needed has Andreas' Acked-by, so
I guess it is fine.

(By the way, I will use this second message to take this chance to
move the modules maintainers in the To: in case it helps, since I
didn't do it in my previous message)

Thanks!

Cheers,
Miguel

[Alvin Sun]

Hi Miguel,

Thanks for taking a look!

On 7/31/26 14:46, Miguel Ojeda wrote:
> On Thu, Jul 23, 2026 at 4:11 AM Alvin Sun <alvi...@linux.dev> wrote:
>> base-commit: b7e5ac83cb16f7ffd11dc23736f84276602100ed
> Was this old tag used for some reason?

That was an oversight on my part - I forgot to rebase onto the latest
tag before sending v9. The series is now based on v7.2-rc4.

>
>> prerequisite-change-id: 20260519-miscdev-use-format-9ab7e83b1c11:v3
>> prerequisite-patch-id: 405b334ff0d48ad350014f05a2321bdbaa025400
>> prerequisite-patch-id: 604b631c81d5423f4ebb2e12ba2d22e9ce371bfc
>> prerequisite-patch-id: cb550d94cefe01920e0d3ced2b2bcbecd76f3907
>> prerequisite-patch-id: 3bc830839742591460cb86d9472c04f4686dc600
>> prerequisite-patch-id: 571058244bc8c7088638d2e3225713011246c7e9
>> prerequisite-patch-id: 347c5a3c6dbef9832bfce8419fc23e6e08ba477f
>> prerequisite-patch-id: 3e202d988b56b88446f7535e90d3f00cf5f15701
> Are all these actually needed? Some seem unrelated (some were already
> applied too).

The prerequisites were just some import formatting changes that the
series depended on at the time. After rebasing onto v7.2-rc4, I was
able to drop all of them - the rebase was clean with no conflicts.

I'll send v10 shortly.

Best regards,
Alvin

[Gary Guo]

On Fri Jul 31, 2026 at 5:34 PM BST, Alvin Sun wrote:
> Hi Miguel,
>
> Thanks for taking a look!
>
> On 7/31/26 14:46, Miguel Ojeda wrote:
>> On Thu, Jul 23, 2026 at 4:11 AM Alvin Sun <alvi...@linux.dev> wrote:
>>> base-commit: b7e5ac83cb16f7ffd11dc23736f84276602100ed
>> Was this old tag used for some reason?
>
> That was an oversight on my part - I forgot to rebase onto the latest
> tag before sending v9. The series is now based on v7.2-rc4.
>
>>
>>> prerequisite-change-id: 20260519-miscdev-use-format-9ab7e83b1c11:v3
>>> prerequisite-patch-id: 405b334ff0d48ad350014f05a2321bdbaa025400
>>> prerequisite-patch-id: 604b631c81d5423f4ebb2e12ba2d22e9ce371bfc
>>> prerequisite-patch-id: cb550d94cefe01920e0d3ced2b2bcbecd76f3907
>>> prerequisite-patch-id: 3bc830839742591460cb86d9472c04f4686dc600
>>> prerequisite-patch-id: 571058244bc8c7088638d2e3225713011246c7e9
>>> prerequisite-patch-id: 347c5a3c6dbef9832bfce8419fc23e6e08ba477f
>>> prerequisite-patch-id: 3e202d988b56b88446f7535e90d3f00cf5f15701
>> Are all these actually needed? Some seem unrelated (some were already
>> applied too).
>
> The prerequisites were just some import formatting changes that the
> series depended on at the time. After rebasing onto v7.2-rc4, I was
> able to drop all of them - the rebase was clean with no conflicts.
>
> I'll send v10 shortly.

If the patch applies cleanly then there's a no need to send a new version.

Best,
Gary

[Alvin Sun]

Sounds good. I'll hold off on v10 then. Thanks!

Best regards,
Alvin

[Petr Pavlu]

Looks good to me. I've replied with Acked-bys for the relevant patches.

--
Thanks,
Petr

[Miguel Ojeda]

On Tue, Aug 11, 2026 at 8:41 AM Alvin Sun <alvi...@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

[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 <alvi...@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]

[Gary Guo]

`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-own...@linux.dev/

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

Best,
Gary

[Danilo Krummrich]

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-own...@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.

[Alvin Sun]

On 8/13/26 00:33, Miguel Ojeda wrote:
> 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.

Hi Miguel,

Thanks for applying the series and catching the stray Acked-by.
It was a v5 series-tag, from before the MAINTAINERS patch existed,
so no need to re-add it. I'll be more careful with tags in future
submissions.

Best regards,
Alvin

[Miguel Ojeda]

On Thu, Aug 13, 2026 at 10:15 AM Alvin Sun <alvi...@linux.dev> wrote:
>
> Thanks for applying the series and catching the stray Acked-by.
> It was a v5 series-tag, from before the MAINTAINERS patch existed,
> so no need to re-add it. I'll be more careful with tags in future
> submissions.

Thanks for confirming! :)

Cheers,
Miguel

[Miguel Ojeda]

On Thu, Aug 13, 2026 at 1:57 AM Gary Guo <ga...@garyguo.net> wrote:
>
> IMO this is the correct way, also consistent with
>
> https://lore.kernel.org/rust-for-linux/20260811-fix-fops-own...@linux.dev/
>
> It might make sense to add this to rust-next.

Yeah, it is also consistent (in the sense of adding a fallback) with
the other fix I added when applying the series for the `macros`
doctest; and the `kernel` crate is not an actual module yet.

I guess yet another solution would be to have an even more local
fallback, but that would be too local in my opinion, i.e. we will want
to use it elsewhere sooner or later.

So I could fold [2] into commit 98f256e27262, but a commit on top is
fine, I will reference that commit from the new one instead.

Ok, done -- Danilo, I took your diff and converted it into a proper
commit, please double-check you are OK with the Signed-off-by:

ec6fcf8a175a ("rust: kernel: add `LocalModule` fallback for
`#[vtable]` `impl`s")

Thanks!

Cheers,
Miguel

[Miguel Ojeda]

On Wed, Aug 12, 2026 at 11:53 PM Danilo Krummrich <da...@kernel.org> wrote:
>
> 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.

Mark: in case it helps to make it clearer and so you don't have to
read much, that [1] diff still needs to be included (i.e. the rest of
the discussion and the commit I added is independent).

Thanks!

Cheers,
Miguel

[Danilo Krummrich]

On Thu Aug 13, 2026 at 11:32 AM CEST, Miguel Ojeda wrote:
> Ok, done -- Danilo, I took your diff and converted it into a proper
> commit, please double-check you are OK with the Signed-off-by:

Of course, thanks!

- Danilo

[Miguel Ojeda]

On Thu, Aug 13, 2026 at 11:32 AM Miguel Ojeda
<miguel.oje...@gmail.com> wrote:
>
> Ok, done -- Danilo, I took your diff and converted it into a proper
> commit, please double-check you are OK with the Signed-off-by:
>
> ec6fcf8a175a ("rust: kernel: add `LocalModule` fallback for
> `#[vtable]` `impl`s")

We also need an `allow(dead_code)` until we actually use it
unconditionally: a2595ed13816 instead.

Cheers,
Miguel

[Alvin Sun]

I was just looking at the difference between the doctest and in-crate
`#[kunit_tests]` test paths — thanks for taking care of this.

I'll look into [3] once the new build system lands.

Best regards,
Alvin

>
> Thanks!
>
> Cheers,
> Miguel