[PATCH v18 0/4] Rust bindings for gem shmem

Lyude Paul posted 4 patches 3 days, 8 hours ago
rust/kernel/drm/gem/shmem.rs | 511 ++++++++++++++++++++++++++++++++++-
rust/kernel/faux.rs          |  16 +-
2 files changed, 512 insertions(+), 15 deletions(-)
[PATCH v18 0/4] Rust bindings for gem shmem
Posted by Lyude Paul 3 days, 8 hours ago
Most of this patch series has already been pushed upstream, this is just
the second half of the patch series that has not been pushed yet + some
additional changes which were required to implement changes requested by
the mailing list. This patch series is originally from Asahi, previously
posted by Daniel Almeida.

The previous version of the patch series can be found here:

	https://patchwork.freedesktop.org/series/164580/

Branch with patches applied available here:

	https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem

This patch series applies on top of drm-rust-next

Patch-series wide changes since V15:
* Fix some major rebasing errors I somehow didn't notice :(
* Drop the dependency on LazyInit, use the trick that Alice suggested
  instead.
* Fix dependency ordering so that Tyr can get the vmap stuff first
  without the other bits.
Patch-series wide changes since V16:
* Fix ordering one more time (SetOnce::reset() doesn't need to come
  before adding vmap functions)
* Rebase against the latest DeviceContext changes from me that got
  pushed.

Lyude Paul (4):
  rust: drm: gem: shmem: Add DmaResvGuard helper
  rust: drm: gem: shmem: Add vmap functions
  rust: faux: Allow retrieving a bound Device
  rust: drm: gem: Introduce shmem::Object::sg_table()

 rust/kernel/drm/gem/shmem.rs | 511 ++++++++++++++++++++++++++++++++++-
 rust/kernel/faux.rs          |  16 +-
 2 files changed, 512 insertions(+), 15 deletions(-)


base-commit: fea3a2dd7d3fc1936211ced5f84420e610435730
-- 
2.54.0
Re: [PATCH v18 0/4] Rust bindings for gem shmem
Posted by Alexandre Courbot 1 day, 2 hours ago
On Fri Jun 5, 2026 at 4:24 AM JST, Lyude Paul wrote:
> Most of this patch series has already been pushed upstream, this is just
> the second half of the patch series that has not been pushed yet + some
> additional changes which were required to implement changes requested by
> the mailing list. This patch series is originally from Asahi, previously
> posted by Daniel Almeida.
>
> The previous version of the patch series can be found here:
>
> 	https://patchwork.freedesktop.org/series/164580/
>
> Branch with patches applied available here:
>
> 	https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem
>
> This patch series applies on top of drm-rust-next
>
> Patch-series wide changes since V15:
> * Fix some major rebasing errors I somehow didn't notice :(
> * Drop the dependency on LazyInit, use the trick that Alice suggested
>   instead.
> * Fix dependency ordering so that Tyr can get the vmap stuff first
>   without the other bits.
> Patch-series wide changes since V16:
> * Fix ordering one more time (SetOnce::reset() doesn't need to come
>   before adding vmap functions)
> * Rebase against the latest DeviceContext changes from me that got
>   pushed.
>

Not a problem of this series, but when trying to build it I initially
got these warnings/errors:

CLIPPY L rust/kernel.o
warning: gendwarfksyms: symbol_print_versions: no information for symbol _RNvMs1_NtNtCsjYlAz7NZ3Sw_4core3mem12maybe_uninitINtB5_11MaybeUninitINtNtCsbuTvttuFvbr_6kernel6devres6DevresINtNtNtNtB18_3drm3gem5shmem10SGTableMapNtNtB1K_5tests11KunitObjectNtNtB1O_6device6UninitEEE16assume_init_dropB18_
...
.vmlinux.export.c:8577:500: warning: null character ignored [-Wnull-character]
 8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
      |      ^
.vmlinux.export.c:8577:501: warning: null character ignored [-Wnull-character]
 8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
      |      ^
.vmlinux.export.c:8577:502: warning: null character ignored [-Wnull-character]
 8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
      |      ^
.vmlinux.export.c:8577:503: warning: null character ignored [-Wnull-character]
 8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
      |      ^
...
.vmlinux.export.c:24529:2: error: embedding a #include directive within macro arguments is not supported
 24529 | #include <linux/module.h>
       |  ^
.vmlinux.export.c:8577:1: note: expansion of macro 'KSYMTAB_FUNC' requested here
 8577 | KSYMTAB_FUNC(_RINvXsi_NtNtCsbuTvttuFvbr_6kernel4sync3arcINtB6_9UniqueArcINtNtNtCsjYlAz7NZ3Sw_4core3mem12maybe_uninit11MaybeUninitIN...
      | ^
.vmlinux.export.c:8577:1: error: unterminated function-like macro invocation
 8577 | KSYMTAB_FUNC(_RINvXsi_NtNtCsbuTvttuFvbr_6kernel4sync3arcINtB6_9UniqueArcINtNtNtCsjYlAz7NZ3Sw_4core3mem12maybe_uninit11MaybeUninitIN...
      | ^
../include/linux/export-internal.h:62:9: note: macro 'KSYMTAB_FUNC' defined here
   62 | #define KSYMTAB_FUNC(name, ns)  __KSYMTAB(name, KSYM_FUNC(name), ns)
      |         ^

This is fixed by [1]. Maybe we should merge that one patch separately
and before the rest? I seem to be seeing these long symbol problems more
often recently.

[1] https://lore.kernel.org/all/20260605-nova-exports-v4-1-e948c287407c@nvidia.com/
Re: [PATCH v18 0/4] Rust bindings for gem shmem
Posted by Gary Guo 16 hours ago
On Sun Jun 7, 2026 at 3:07 AM BST, Alexandre Courbot wrote:
> On Fri Jun 5, 2026 at 4:24 AM JST, Lyude Paul wrote:
>> Most of this patch series has already been pushed upstream, this is just
>> the second half of the patch series that has not been pushed yet + some
>> additional changes which were required to implement changes requested by
>> the mailing list. This patch series is originally from Asahi, previously
>> posted by Daniel Almeida.
>>
>> The previous version of the patch series can be found here:
>>
>> 	https://patchwork.freedesktop.org/series/164580/
>>
>> Branch with patches applied available here:
>>
>> 	https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem
>>
>> This patch series applies on top of drm-rust-next
>>
>> Patch-series wide changes since V15:
>> * Fix some major rebasing errors I somehow didn't notice :(
>> * Drop the dependency on LazyInit, use the trick that Alice suggested
>>   instead.
>> * Fix dependency ordering so that Tyr can get the vmap stuff first
>>   without the other bits.
>> Patch-series wide changes since V16:
>> * Fix ordering one more time (SetOnce::reset() doesn't need to come
>>   before adding vmap functions)
>> * Rebase against the latest DeviceContext changes from me that got
>>   pushed.
>>
>
> Not a problem of this series, but when trying to build it I initially
> got these warnings/errors:
>
> CLIPPY L rust/kernel.o
> warning: gendwarfksyms: symbol_print_versions: no information for symbol _RNvMs1_NtNtCsjYlAz7NZ3Sw_4core3mem12maybe_uninitINtB5_11MaybeUninitINtNtCsbuTvttuFvbr_6kernel6devres6DevresINtNtNtNtB18_3drm3gem5shmem10SGTableMapNtNtB1K_5tests11KunitObjectNtNtB1O_6device6UninitEEE16assume_init_dropB18_

IMO we really shouldn't use Clippy to generate code. We spent too much effort in
fixing codegen issues that are only present when driven by clippy.

We should just run a check phase with clippy to get the lints only, and then use
rustc to generate actual code.

Best,
Gary

> ...
> .vmlinux.export.c:8577:500: warning: null character ignored [-Wnull-character]
>  8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
>       |      ^
> .vmlinux.export.c:8577:501: warning: null character ignored [-Wnull-character]
>  8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
>       |      ^
> .vmlinux.export.c:8577:502: warning: null character ignored [-Wnull-character]
>  8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
>       |      ^
> .vmlinux.export.c:8577:503: warning: null character ignored [-Wnull-character]
>  8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
>       |      ^
> ...
> .vmlinux.export.c:24529:2: error: embedding a #include directive within macro arguments is not supported
>  24529 | #include <linux/module.h>
>        |  ^
> .vmlinux.export.c:8577:1: note: expansion of macro 'KSYMTAB_FUNC' requested here
>  8577 | KSYMTAB_FUNC(_RINvXsi_NtNtCsbuTvttuFvbr_6kernel4sync3arcINtB6_9UniqueArcINtNtNtCsjYlAz7NZ3Sw_4core3mem12maybe_uninit11MaybeUninitIN...
>       | ^
> .vmlinux.export.c:8577:1: error: unterminated function-like macro invocation
>  8577 | KSYMTAB_FUNC(_RINvXsi_NtNtCsbuTvttuFvbr_6kernel4sync3arcINtB6_9UniqueArcINtNtNtCsjYlAz7NZ3Sw_4core3mem12maybe_uninit11MaybeUninitIN...
>       | ^
> ../include/linux/export-internal.h:62:9: note: macro 'KSYMTAB_FUNC' defined here
>    62 | #define KSYMTAB_FUNC(name, ns)  __KSYMTAB(name, KSYM_FUNC(name), ns)
>       |         ^
>
> This is fixed by [1]. Maybe we should merge that one patch separately
> and before the rest? I seem to be seeing these long symbol problems more
> often recently.
>
> [1] https://lore.kernel.org/all/20260605-nova-exports-v4-1-e948c287407c@nvidia.com/
Re: [PATCH v18 0/4] Rust bindings for gem shmem
Posted by Miguel Ojeda 13 hours ago
On Sun, Jun 7, 2026 at 2:17 PM Gary Guo <gary@garyguo.net> wrote:
>
> IMO we really shouldn't use Clippy to generate code. We spent too much effort in
> fixing codegen issues that are only present when driven by clippy.
>
> We should just run a check phase with clippy to get the lints only, and then use
> rustc to generate actual code.

Yeah, given the trouble it is giving, I think that will probably be a
better approach medium term. I don't love it, because the original
idea was to avoid such an extra phase, but it is definitely better vs.
random source code changes...

We could also increase the symbol size-related variables
(`KSYM_NAME_LEN`, `SZ` in `modpost`...) only for Clippy builds to a
ludicrous value. The extra phase approach would avoid surprises more
generally though, so I like it in that sense, and has the implicit
advantage of avoiding someone using a Clippy kernel in production by
mistake.

Ok, I can take a look at that. For now, I will pick the other patch.

Cheers,
Miguel
Re: [PATCH v18 0/4] Rust bindings for gem shmem
Posted by Miguel Ojeda 16 hours ago
On Sun, Jun 7, 2026 at 4:08 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> This is fixed by [1]. Maybe we should merge that one patch separately
> and before the rest? I seem to be seeing these long symbol problems more
> often recently.
>
> [1] https://lore.kernel.org/all/20260605-nova-exports-v4-1-e948c287407c@nvidia.com/

I can take that one via `rust-next` unless someone shouts -- Ack's appreciated.

Cheers,
Miguel