Em Sat, 10 Oct 2020 12:53:49 +0200 Daniel Vetter daniel.vetter@ffwll.ch escreveu:
Hi Mauro,
You might want to read the patches more carefully, because what you're demanding is what my patches do. Short summary:
- if STRICT_FOLLOW_PFN is set:
a) normal memory is handled as-is (i.e. your example works) through the addition of FOLL_LONGTERM. This is the "pin the pages correctly" approach you're demanding b) for non-page memory (zerocopy sharing before dma-buf was upstreamed is the only use-case for this) it is correctly rejected with -EINVAL
- if you do have blobby userspace which requires the zero-copy using
userptr to work, and doesn't have any of the fallbacks implemented that you describe, this would be a regression. That's why STRICT_FOLLOW_PFN can be unset. And yes there's a real security issue in this usage, Marek also confirmed that the removal of the vma copy code a few years ago essentially broke even the weak assumptions that made the code work 10+ years ago when it was merged.
so tdlr; Everything you described will keep working even with the new flag set, and everything you demand must be implemented _is_ implemented in this patch series.
Also please keep in mind that we are _not_ talking about the general userptr support that was merge ~20 years ago. This patch series here is _only_ about the zerocpy userptr support merged with 50ac952d2263 ("[media] videobuf2-dma-sg: Support io userptr operations on io memory") in 2013.
Ok, now it is making more sense. Please update the comments for patch 10/17 to describe the above.
We need some time to test this though, in order to check if no regressions were added (except the ones due to changeset 50ac952d2263).
Why this hack was merged in 2013 when we merged dma-buf almost 2 years before that I have no idea about. Imo that patch simply should never have landed, and instead dma-buf support prioritized.
If I recall correctly, we didn't have any DMABUF support at the media subsystem, back on 2013.
It took some time for the DMA-BUF to arrive at media, as this was not a top priority. Also, there aren't many developers that understand the memory model well enough to implement DMA-BUF support and touch the VB2 code, which is quite complex, as it supports lots of different ways for I/O, plus works with vmalloc, DMA contig and DMA scatter/gather.
Changes there should carefully be tested against different drivers, in order to avoid regressions on it.
Cheers, Daniel
Thanks, Mauro