> anyone with a mp system can confirm this?
Yes, I've confirmed by experiment that duppage(lkp) can return
with lkp->ref > 1.
Is what you've found related to the "XXX - here's a bug" comment
in duppage? Maybe that's what really needs fixing.
no, this is different.
the XXX - there's a bug is about the new page that
duppage() makes. it explains a race where the new
page is on the freelist and the image cache.
whats important is that when someone (lookpage)
locks the page, its refcount and image/daddr is
consistent wich should be the cas
> the problem we have is that we temporarily unlock
> p to acquire palloc lock, wich opens a chance for
> someone to take a ref on p, but duppage doesnt
> recheck after reqcquiering the p lock.
>
> if this happens, duppage() has to return and let
> fixfault() make a copy for its segment.
That mak
fixfault() in fault.c is the only user of duppage().
in 9front, i changed the return type of duppage to void.
fixfault() now looks like this:
...
if(lkp->image == &swapimage)
ref = lkp->ref + swapcount(lkp->daddr);
else
