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.