Hi, > > Anything building on shmem helpers should be able to use > > obj->filp->f_mapping, right? So allocating an inode unconditionally > > doesn't look like a good plan. > > Not sure the shmem helpers forward the mmap to the underlying shmem file, > so not sure this is the greatest way either.
I think so, shmem helpers already zap the fake offset, and this would not work without per-object address space I think. > > Guess I'll go look at ttm-local changes for starters and see how it > > goes. > > I think for ttm just consistently using the one per-device mapping for > everything, with all the fake offsets, is probably the quickest route. Hmm, not clear how to fit dmabufs into this. dmabufs already have their own file, inode and address space. I'm not sure you can switch that over to the per-device mapping in the first place, and even if you can I have my doubts this is a good idea from a security point of view ... cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
