On Wed, 2009-02-04 at 21:10 -0800, Roland Dreier wrote: > > Note that g_u_p() has all sort of shortcommings... we were discussing > > some of that recently due to bugs reported from the field. > > > > The problem mostly is that you cannot guarantee that the physical page > > will remain mapped to that virtual address in the process. For example, > > if your code is part of some library used by an application, and that > > application somewhere does a fork/exec (for example, a system() call to > > run a shell helper), copy-on-write will hit, and you may end up with > > the child process getting the original physical page and the original > > process getting the copy... > > Believe me, I'm well aware of that. We added VM_DONTCOPY to allow apps > to fork() without the child triggering COW, but that means only the > parent process can use the mapped memory (and the app has to worry about > page boundaries etc).
Right, but then you need to set that in the VMA's, and thus gone is your nice fast g_u_p() that doesn't touch VMAs :-) > Yes, but unfortunately MPI says apps can allocate memory however they > damn well please... in any case these issues are all-too-well-known in > the RDMA world for quite a while. Yup. What do you think of the idea of pre-COWing pages with an elevated count at fork time ? Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
