Re: [FYI] tux3: Core changes

[Pavel Machek <pavel@ucw.cz>]

On Fri 2015-05-15 02:38:33, Daniel Phillips wrote:
> 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,

Umm. Why do you think it is only issue for executable files?

I'm free to mmap() any file, and then execute from it.

/lib/ld-linux.so /path/to/binary

is known way to exec programs that do not have x bit set.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html