On Mon, Nov 19, 2018 at 07:19:04PM +0000, Christopher Lameter wrote: > On Mon, 19 Nov 2018, Jerome Glisse wrote: > > > > IIRC this is solved in IB by automatically calling > > > madvise(MADV_DONTFORK) before creating the MR. > > > > > > MADV_DONTFORK > > > .. This is useful to prevent copy-on-write semantics from changing the > > > physical location of a page if the parent writes to it after a > > > fork(2) .. > > > > This would work around the issue but this is not transparent ie > > range marked with DONTFORK no longer behave as expected from the > > application point of view. > > Why would anyone expect a range registered via MR behave as normal? Device > I/O is going on into that range. Memory is already special. > > > > Also it relies on userspace doing the right thing (which is not > > something i usualy trust :)). > > This has been established practice for 15 or so years in a couple of use > cases. Again user space already has to be doing special things in order to > handle RDMA is that area. Yes RDMA as an existing historical track record and thus people should now be aware of its limitation. What i am fighting against is new addition to kernel that pretend to do SVA (share virtual address) while their hardware is not realy doing SVA. SVA with IOMMU and ATS/PASID is fine, SVA in software with device driver that abide to mmu notifier is fine. Anything else is not. So i am just worrying about new user and making sure they under- stand what is happening and not sell to their user something false. Cheers, Jérôme
