Messages in this thread | | | Subject | Re: Changing vma->vm_file in dma_buf_mmap() | From | Christian König <> | Date | Wed, 16 Sep 2020 16:14:19 +0200 |
| |
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
| |