On Tue, Oct 06, 2020 at 08:23:23AM +0200, Daniel Vetter wrote: > On Tue, Oct 6, 2020 at 1:41 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > > > On Tue, Oct 06, 2020 at 12:43:31AM +0200, Daniel Vetter wrote: > > > > > > iow I think I can outright delete the frame vector stuff. > > > > > > Ok this doesn't work, because dma_mmap always uses a remap_pfn_range, > > > which is a VM_IO | VM_PFNMAP vma and so even if it's cma backed and > > > not a carveout, we can't get the pages. > > > > If CMA memory has struct pages it probably should be mmap'd with > > different flags, and the lifecycle of the CMA memory needs to respect > > the struct page refcount? > > I guess yes and no. The problem is if there's pagecache in the cma > region, pup(FOLL_LONGTERM) needs to first migrate those pages out of > the cma range. Because all normal page allocation in cma regions must > be migratable at all times. Eh? Then how are we doing follow_pfn() on this stuff and not being completely broken? The entire point of this framevec API is to pin the memory and preventing it from moving around. Sounds like it is fundamentally incompatible with CMA. Why is something trying to mix the two? > This is actually worse than the gpu case I had in mind, where at most > you can sneak access other gpu buffers. With cma you should be able to > get at arbitrary pagecache (well anything that's GFP_MOVEABLE really). > Nice :-( Ah, we have a winner :\ Jason _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
