lkml.org 
[lkml]   [2020]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Changing vma->vm_file in dma_buf_mmap()
    From
    Date
    Am 16.09.20 um 16:07 schrieb Jason Gunthorpe:
    > On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote:
    >
    >> But within the driver, we generally need thousands of these, and that
    >> tends to bring fd exhaustion problems with it. That's why all the private
    >> buffer objects which aren't shared with other process or other drivers are
    >> handles only valid for a specific fd instance of the drm chardev (each
    >> open gets their own namespace), and only for ioctls done on that chardev.
    >> And for mmap we assign fake (but unique across all open fd on it) offsets
    >> within the overall chardev. Hence all the pgoff mangling and re-mangling.
    > Are they still unique struct files? Just without a fdno?

    Yes, exactly.

    >> Hence why we'd like to be able to forward aliasing mappings and adjust the
    >> file and pgoff, while hopefully everything keeps working. I thought this
    >> would work, but Christian noticed it doesn't really.
    > It seems reasonable to me that the dma buf should be the owner of the
    > VMA, otherwise like you say, there is a big mess attaching the custom
    > vma ops and what not to the proper dma buf.
    >
    > I don't see anything obviously against this in mmap_region() - why did
    > Chritian notice it doesn't really work?

    To clarify I think this might work.

    I just had the same "Is that legal?", "What about security?", etc..
    questions you raised as well.

    It seems like a source of trouble so I thought better ask somebody more
    familiar with that.

    Christian.

    >
    > Jason

    \
     
     \ /
      Last update: 2020-09-16 22:59    [W:2.434 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site