Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()

[Daniel Vetter <daniel@ffwll.ch>]

On Thu, Sep 17, 2020 at 6:39 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Thu, Sep 17, 2020 at 06:06:14PM +0200, Christian König wrote:
> > > > If it is already taking a page fault I'm not sure the extra function
> > > > call indirection is going to be a big deal. Having a uniform VMA
> > > > sounds saner than every driver custom rolling something.
> > > >
> > > > When I unwound a similar mess in RDMA all the custom VMA stuff in the
> > > > drivers turned out to be generally buggy, at least.
> > > >
> > > > Is vma->vm_file->private_data universally a dma_buf pointer at least?
> > > Nope. I think if you want this without some large scale rewrite of a
> > > lot of code we'd need a vmops->get_dmabuf or similar. Not pretty, but
> > > would get the job done.
> >
> > Yeah, agree that sounds like the simplest approach.
>
> I don't think that will fly, it is clearly only papering over a mess
> inside DRM/dma buf :\

dma-buf started out as something to paper over the disjoint mess of
allocators, since it was pretty clear to anyone involved we're not
going to unify them anytime soon, if ever. So the mess pretty much is
bound to stay.

I think most reasonable thing would be to throw a common vmops in
there somehow, but even that means some large scale surgery across
every driver/subsystem involved in dma-buf. It wouldn't unify
anything, all it would give you is a constant vma->vm_ops to do some
kind of upcasting. And that would still only give you a slightly less
opaque pointer with a callback to upcast to a dma-buf in some
driver/subsystem specific way.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch