lkml.org 
[lkml]   [2021]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2021-12-18 01:50    [W:1.616 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site