On Mon, Nov 19, 2018 at 12:48:01PM +0200, Leon Romanovsky wrote: > On Mon, Nov 19, 2018 at 05:19:10PM +0800, Kenneth Lee wrote: > > On Mon, Nov 19, 2018 at 05:14:05PM +0800, Kenneth Lee wrote: > > > On Thu, Nov 15, 2018 at 04:54:55PM +0200, Leon Romanovsky wrote: > > > > On Thu, Nov 15, 2018 at 04:51:09PM +0800, Kenneth Lee wrote: > > > > > On Wed, Nov 14, 2018 at 06:00:17PM +0200, Leon Romanovsky wrote: > > > > > > On Wed, Nov 14, 2018 at 10:58:09AM +0800, Kenneth Lee wrote: > > > > > > > > On Mon, Nov 12, 2018 at 03:58:02PM +0800, Kenneth Lee wrote:
[...] > > > > memory exposed to user is properly protected from security point of > > > > view. > > > > 3. "stop using the page for a while for the copying" - I'm not fully > > > > understand this claim, maybe this article will help you to better > > > > describe : https://lwn.net/Articles/753027/ > > > > > > This topic was being discussed in RFCv2. The key problem here is that: > > > > > > The device need to hold the memory for its own calculation, but the > > > CPU/software > > > want to stop it for a while for synchronizing with disk or COW. > > > > > > If the hardware support SVM/SVA (Shared Virtual Memory/Address), it is > > > easy, the > > > device share page table with CPU, the device will raise a page fault when > > > the > > > CPU downgrade the PTE to read-only. > > > > > > If the hardware cannot share page table with the CPU, we then need to have > > > some way to change the device page table. This is what happen in ODP. It > > > invalidates the page table in device upon mmu_notifier call back. But > > > this cannot > > > solve the COW problem: if the user process A share a page P with device, > > > and A > > > forks a new process B, and it continue to write to the page. By COW, the > > > process B will keep the page P, while A will get a new page P'. But you > > > have > > > no way to let the device know it should use P' rather than P. > > I didn't hear about such issue and we supported fork for a long time. > Just to comment on this, any infiniband driver which use umem and do not have ODP (here ODP for me means listening to mmu notifier so all infiniband driver except mlx5) will be affected by same issue AFAICT. AFAICT there is no special thing happening after fork() inside any of those driver. So if parent create a umem mr before fork() and program hardware with it then after fork() the parent might start using new page for the umem range while the old memory is use by the child. The reverse is also true (parent using old memory and child new memory) bottom line you can not predict which memory the child or the parent will use for the range after fork(). So no matter what you consider the child or the parent, what the hw will use for the mr is unlikely to match what the CPU use for the same virtual address. In other word: Before fork: CPU parent: virtual addr ptr1 -> physical address = 0xCAFE HARDWARE: virtual addr ptr1 -> physical address = 0xCAFE Case 1: CPU parent: virtual addr ptr1 -> physical address = 0xCAFE CPU child: virtual addr ptr1 -> physical address = 0xDEAD HARDWARE: virtual addr ptr1 -> physical address = 0xCAFE Case 2: CPU parent: virtual addr ptr1 -> physical address = 0xBEEF CPU child: virtual addr ptr1 -> physical address = 0xCAFE HARDWARE: virtual addr ptr1 -> physical address = 0xCAFE This apply for every single page and is not predictable. This only apply to private memory (mmap() with MAP_PRIVATE) I am not familiar enough with RDMA user space API contract to know if this is an issue or not. Note that this can not be fix, no one should have done umem without ODP like mlx5. For this to work properly you need sane hardware like mlx5. Cheers, Jérôme
