Re: [Intel-gfx] [PATCH] drm/vgem: Replace vgem_object_funcs with the common drm shmem helper

[Daniel Vetter <daniel@ffwll.ch>]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel