diff options
| author | Lyude Paul <lyude@redhat.com> | 2026-06-12 15:43:36 -0400 |
|---|---|---|
| committer | Lyude Paul <lyude@redhat.com> | 2026-06-25 14:25:54 -0400 |
| commit | 616c229ab010a31c5d1f793b925c7fb2eaad664c (patch) | |
| tree | 11f2ed022f4e28a9f86de833b861ca2540c33013 /io_uring/loop.h | |
| parent | 52aab89ad32dfa50ea6874cb5013e6f75894320f (diff) | |
| download | linux-next-616c229ab010a31c5d1f793b925c7fb2eaad664c.tar.gz linux-next-616c229ab010a31c5d1f793b925c7fb2eaad664c.zip | |
rust: drm: gem: Introduce shmem::Object::sg_table()
In order to do this, we need to be careful to ensure that any interface we
expose for scatterlists ensures that any mappings created from one are
destroyed on driver-unbind. To do this, we introduce a Devres resource into
shmem::Object that we use in order to ensure that we release any SGTable
mappings on driver-unbind.
There's some other slightly unfortunate caveats of this:
* Drivers don't have explicit control at the moment over when unmapping
happens (which is exactly the same as the C side atm, so it might not be
a problem).
* We can't just return `SGTableMap` to the user through an Arc to attempt
to fix the last caveat - because that implies the gem object would need
to hold a reference count to the scatterlist mapping, which just leaves
us with the same problem.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260612194436.585385-5-lyude@redhat.com
Diffstat (limited to 'io_uring/loop.h')
0 files changed, 0 insertions, 0 deletions
