On 05/14/2015 08:06 PM, Rik van Riel wrote: > On 05/14/2015 08:06 PM, Daniel Phillips wrote: >>> The issue is that things like ptrace, AIO, infiniband >>> RDMA, and other direct memory access subsystems can take >>> a reference to page A, which Tux3 clones into a new page B >>> when the process writes it. >>> >>> However, while the process now points at page B, ptrace, >>> AIO, infiniband, etc will still be pointing at page A. >>> >>> This causes the process and the other subsystem to each >>> look at a different page, instead of at shared state, >>> causing ptrace to do nothing, AIO and RDMA data to be >>> invisible (or corrupted), etc... >> >> Is this a bit like page migration? > > Yes. Page migration will fail if there is an "extra" > reference to the page that is not accounted for by > the migration code. > > Only pages that have no extra refcount can be migrated. > > Similarly, your cow code needs to fail if there is an > extra reference count pinning the page. As long as > the page has a user that you cannot migrate, you cannot > move any of the other users over. They may rely on data > written by the hidden-to-you user, and the hidden-to-you > user may write to the page when you think it is a read > only stable snapshot. Please bear with me as I study these cases one by one. First one is ptrace. Only for executable files, right? Maybe we don't need to fork pages in executable files, Uprobes... If somebody puts a breakpoint in a page and we fork it, the replacement page has a copy of the breakpoint, and all the code on the page. Did anything break? Note: we have the option of being cowardly and just not doing page forking for mmapped files, or certain kinds of mmapped files, etc. But first we should give it the old college try, to see if absolute perfection is possible and practical. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
