Messages in this thread | | | Date | Fri, 17 Dec 2021 20:50:29 -0400 | From | Jason Gunthorpe <> | Subject | Re: [PATCH v1 06/11] mm: support GUP-triggered unsharing via FAULT_FLAG_UNSHARE (!hugetlb) |
| |
On Fri, Dec 17, 2021 at 10:04:11PM +0100, David Hildenbrand wrote:
> > To remind all, the GUP users, like RDMA, VFIO use > > FOLL_FORCE|FOLL_WRITE to get a 'r/o pin' specifically because of the > > I heard that statement often. Can you point me at the code? > > VFIO: drivers/vfio/vfio_iommu_type1.c > > vaddr_get_pfns() will end up doing a > pin_user_pages_remote(FOLL_LONGTERM) without > FOLL_FORCE|FOLL_WRITE.
> Is that added automatically internally?
No, it is just that VFIO is broken in this regard. AFAIK VFIO users rarely use the read-only mode and haven't noticed this bug yet.
You can search for FOLL_FORCE and see the drivers that do it this way:
drivers/misc/habanalabs/common/memory.c: FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM, drivers/infiniband/core/umem.c: gup_flags |= FOLL_FORCE; drivers/media/v4l2-core/videobuf-dma-sg.c: unsigned int flags = FOLL_FORCE; drivers/media/common/videobuf2/frame_vector.c: FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
[etc]
No doubt there are others that do it right and wrong, this is badly documented and misunderstood.
> But this series really just wants to fix the security issue as "part 1". > Without any more breakages.
Sure, I'm just trying to understand why this example was brought up.
Jason
| |