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