On Fri, Jun 23, 2023 at 01:37:58PM -0300, Jason Gunthorpe wrote: > On Fri, Jun 23, 2023 at 12:35:45PM -0400, Peter Xu wrote: > > > It seems the previous concern on using gup was majorly fork(), if this is it: > > > > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#comment_414213 > > Fork and GUP have been fixed since that comment anyhow there is no > longer a problem using GUP and fork together. Ah, I read it previously as a requirement that the child will also be able the see the same / coherent page when manipulating the dmabuf later after fork(), e.g., the udmabuf can be created before fork(). > > > Could it also be guarded by just making sure the pages are MAP_SHARED when > > creating the udmabuf, if fork() is a requirement of the feature? > > Also a resaonable thing to do > > > For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs > > file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but > > at least not F_SEAL_WRITE with current impl), and fault a new page into the > > page cache? > > It becomes incoherent just like all other GUP users if userspace > explicitly manipulates the VMAs. It is no different to what happens > with VFIO, qemu should treat this memory the same as it does for VFIO > memory. Agreed. -- Peter Xu
