On 04/05/2015 10:47, Gleb Smirnoff wrote: > On Sun, Apr 05, 2015 at 06:37:58AM -0700, David Wolfskill wrote: > D> It ocurred rather late in the transition to multi-user mode, but > D> prior to starting xdm (on my laptop). > D> > D> Previous (working) head/i386 for this machine was r281074. > D> > D> Here's the first bit of the crashinfo (yes, I have a crash dump): > D> > D> g1-254.catwhisker.org dumped core - see /var/crash/vmcore.3 > D> > D> Sun Apr 5 06:18:44 PDT 2015 > D> > D> FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1561 > r281106M/281106:1100067: Sun Apr 5 06:01:06 PDT 2015 > r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 > D> > D> panic: Lock vm object not exclusively locked @ > /usr/src/sys/vm/vm_page.c:2637 > > This is r281079. > > Since vm_page_advise() may call vm_page_dirty() in the MADV_DONTNEED case, > the assertion is valid. So, looks like vm_fault_dontneed() needs W-lock on > the first_object. >
Actually, what I forgot was that vm_page_advise(MADV_FREE) clears the page's dirty field, and that is why an exclusive lock is asserted. As explained in vm_page.h, the pmap is allowed to set the dirty field to all ones without any locking. Moreover, the new "fast" path in vm_fault() sets the dirty field with only a read lock held. vm_page_advise(MADV_DONTNEED) isn't really any different from the fast path. Need to think a bit ... _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"