Re: [rfc][patch] remove racy sync_page?

[Jens Axboe <axboe@suse.de>]

On Thu, Jun 01 2006, Nick Piggin wrote:
> Hugh Dickins wrote:
> >On Wed, 31 May 2006, Nick Piggin wrote:
> >
> >>Jens Axboe wrote:
> >>
> >>>Maybe I'm being dense, but I don't see a problem there. You _should_
> >>>call the new mapping sync page if it has been migrated.
> >>
> >>But can some other thread calling lock_page first find the old mapping,
> >>and then run its ->sync_page which finds the new mapping? While it may
> >>not matter for anyone in-tree, it does break the API so it would be
> >>better to either fix it or rip it out than be silently buggy.
> >
> >
> >Splicing a page from one mapping to another is rather worrying/exciting,
> >but it does look safely done to me.  remove_mapping checks page_count
> >while page lock and old mapping->tree_lock are held, and gives up if
> >anyone else has an interest in the page.  And we already know it's
> >unsafe to lock_page without holding a reference to the page, don't we?
> 
> Oh, that's true. I had thought that splice allows stealing pages with
> an elevated refcount, which Jens was thinking about at one stage. But
> I see that code isn't in mainline. AFAIKS it would allow other
> ->pin()ers to attempt to lock the page while it was being stolen.

It got me in trouble, and we were already way too late into 2.6.17 to
take on more risky stuff (splice already had a few!). So right now the
page is definitely pruned and single while being stolen.

-- 
Jens Axboe