On Mon, Oct 12, 2020 at 03:01:09PM +0100, Chris Wilson wrote:
Quoting Daniel Vetter (2020-10-12 14:55:07)
On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson chris@chris-wilson.co.uk wrote:
Quoting Daniel Vetter (2020-10-09 17:16:06)
On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson chris@chris-wilson.co.uk wrote:
vgem is a minimalistic driver that provides shmemfs objects to userspace that may then be used as an in-memory surface and transported across dma-buf to other drivers. Since it's introduction, drm_gem_shmem_helper now provides the same shmemfs facilities and so we can trim vgem to wrap the helper.
Signed-off-by: Chris Wilson chris@chris-wilson.co.uk
drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/vgem/vgem_drv.c | 281 ++------------------------------ drivers/gpu/drm/vgem/vgem_drv.h | 11 -- 3 files changed, 13 insertions(+), 280 deletions(-)
Nice diffstat :-)
Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch
Unfortunately I had to drop the drm_gem_prime_mmap() since the existing expectation is that we hand the faulthandler off to shmemfs so we can release the module while the memory is exported.
That sounds like a broken igt. Once we have refcounting for outstanding dma_fence/buf or anything else we'll block unloading of the module (not unbinding of the driver). Which one is that?
The dma-buf is closed; all that remains is the mmap. Then from the perspective of the module, there is no reference back to the module since we delegate handling of the mmap back to the owner, the shmemfs builtin. That allows us to remove the module as its object code is no longer required.
Oh I know how that's possible, I wonder about which testcase encodes that. Because it really shouldn't, since that's quite far away from the rough consensus that we cobbled together on dri-devel a few months ago about how hotunplug should work. If it's a vgem test, meh, we can change that whenever. But if it's a generic test that falls over on vgem, then we need to teach it better assumptions. -Daniel