Quoting Daniel Vetter (2020-10-12 15:12:50) > 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@xxxxxxxxxxxxxxxxxx> wrote: > > > > Quoting Daniel Vetter (2020-10-09 17:16:06) > > > > > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > > > > > > --- > > > > > > 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@xxxxxxxx> > > > > > > > > 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. We intentionally copied the module unload behaviour from i915. -Chris _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
