[Intel-gfx] [PATCH v3 3/3] drm/vgem: Keep a reference to the dmabuf when mmaped
Daniel Vetter
daniel at ffwll.ch
Wed Oct 5 13:42:13 UTC 2016
On Wed, Oct 05, 2016 at 02:40:09PM +0100, Chris Wilson wrote:
> On Wed, Oct 05, 2016 at 03:11:00PM +0200, Daniel Vetter wrote:
> > On Fri, Sep 30, 2016 at 02:59:59PM +0100, Chris Wilson wrote:
> > > In order to keep the dmabuf alive whilst the mmap is, we need to hold a
> > > reference to the dmabuf and not the backing object. This is important as
> > > the dmabuf not only keeps the object alive, but also the device so that
> > >
> > > dmabuf = vgem_create_dmabuf();
> > > ptr = mmap(... dmabuf ...);
> > > close(dmabuf);
> > >
> > > persists across module-unload as well as device closure.
> >
> > I don't see where we grab the ref to the dma-buf here instead of the
> > backing storage. And doesn't the exact same issue happen when you use dumb
> > mmap? Or maybe I'm just a bit confused about what's going on here ...
>
> The reference to the dmabuf is in vma->vm_file, which was used to keep
> the module alive. So this might be overzealous, in that there shouldn't
> be a way to get back from the shmemfs object to the module. However,
> that does make me aware of a failure path we have in patches that do add
> callbacks from shmemfs to the driver...
>
> At least using the ptr after closing the module is ok. So this patch is
> not required.
I think if we entirely redirect the mmap to shmem, and not forget to also
update vm_file, the driver could get unloaded without ill effects. I'll
leave this one out for now, picked up 1&2 from v4 to -misc meanwhile.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list