svn commit: r254150 - head/sys/vm

[John Baldwin]

On Friday, August 09, 2013 4:40:10 pm Alan Cox wrote:
> 
> On Aug 9, 2013, at 1:34 PM, Alan Cox wrote:
> 
> > 
> > On Aug 9, 2013, at 12:56 PM, John Baldwin wrote:
> > 
> >> On Friday, August 09, 2013 12:43:50 pm David E. O'Brien wrote:
> >>> Author: obrien
> >>> Date: Fri Aug  9 16:43:50 2013
> >>> New Revision: 254150
> >>> URL: http://svnweb.freebsd.org/changeset/base/254150
> >>> 
> >>> Log:
> >>> Add missing 'VPO_BUSY' from r254141 to fix kernel build break.
> >>> 
> >>> Modified:
> >>> head/sys/vm/vm_page.h
> >> 
> >> This can't possibly be correct as r254138 just removed this flag.  If it 
isn't 
> >> obvious how to fix the uses added back in r254141, then r254141 should be 
> >> reverted instead.
> >> 
> >> Hmm, looking at the relevant bits of r254141, it doesn't look obvious:
> >> 
> >> +       /* Detach the old page from the resident tailq. */
> >> +       TAILQ_REMOVE(&object->memq, mold, listq);
> >> +       vm_page_lock(mold);
> > 
> > Replace the next four lines with
> > 
> > 	vm_page_xunbusy(mold);
> > 
> 
> On second thought, no, because it could lead to lock recursion.

What about this.  I think this matches the common idiom I've seen in
other places.

Index: vm_page.c
===================================================================
--- vm_page.c   (revision 254158)
+++ vm_page.c   (working copy)
@@ -1202,12 +1202,9 @@
        /* Detach the old page from the resident tailq. */
        TAILQ_REMOVE(&object->memq, mold, listq);
        vm_page_lock(mold);
-       if (mold->oflags & VPO_BUSY) {
-               mold->oflags &= ~VPO_BUSY;
-               vm_page_flash(mold);
-       }
        mold->object = NULL;
        vm_page_unlock(mold);
+       vm_page_xunbusy(mold);
 
        /* Insert the new page in the resident tailq. */
        if (mpred != NULL)


-- 
John Baldwin