rust/kernel/drm/gem/shmem.rs | 511 ++++++++++++++++++++++++++++++++++- rust/kernel/faux.rs | 16 +- 2 files changed, 512 insertions(+), 15 deletions(-)
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
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/
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/
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
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
© 2016 - 2026 Red Hat, Inc.