Hej, this is triggered by the discussion of gem/shmem.rs SGTableMap issues in [1] which has an additional issue with imported object. Imported objects are supported since GEM shmem's AllocOps use drm_gem_shmem_prime_import_sg_table() as gem_prime_import_sg_table which sets the same function pointer field in struct drm_driver.
The code is broken in two ways. SGTableMap::drop() calls __drm_gem_shmem_free_sgt_locked() uncondiftionally which it must not do for imported objects as the object does not own `sgt`. The second issue is that the imported object is allocated by __drm_gem_shmem_create() with sizeof(struct drm_gem_shmem_object) as size instead of the size of Rust's Object<T>. The second issue is already fixed in tyr's downstream driver by adding a `gem_create_object` callback which is used instead of the minimal allocation in the C helper. The first issue is fixed in the Asahi downstream driver together with a drm_gem_is_imported() wrapper change taken from the tyr downstream driver. All three patches are tested in the Asahi downstream driver. As this is unused code in-tree I marked the fixes as not suitable for stable backports. The known downstream users of the code are aware of the issues and carry fixes downstream. I don't expect new Rust DRM drivers to be based on the (old) stable trees. Link: https://lore.kernel.org/rust-for-linux/[email protected]/ [1] Signed-off-by: Janne Grunau <[email protected]> --- Janne Grunau (1): rust: drm: gem: shmem: Do not free SG table of imported objects Sami Tolvanen (2): rust: drm: gem: shmem: implement gem_create_object for prime imports rust: drm: gem: add an is_imported() accessor drivers/gpu/drm/nova/gem.rs | 4 +++ drivers/gpu/drm/tyr/gem.rs | 4 +++ rust/helpers/drm.c | 6 +++++ rust/kernel/drm/gem/mod.rs | 16 ++++++++++++ rust/kernel/drm/gem/shmem.rs | 62 +++++++++++++++++++++++++++++++++++++++++++- 5 files changed, 91 insertions(+), 1 deletion(-) --- base-commit: 3497a403264b094ebd61b8b755165d56e7d9dc37 change-id: 20261026-rust-drm-gem-shmem-imported-sgt-85c4a45be283 Best regards, -- Janne Grunau <[email protected]>
