Re: panic: Lock vm object not exclusively locked _at_ /usr/src/sys/vm/vm_page.c:2637

On 04/05/2015 19:49, Rui Paulo wrote:
> On Apr 5, 2015, at 13:07, Alan Cox <alc_at_rice.edu> wrote:
>> On 04/05/2015 14:34, Gleb Smirnoff wrote:
>>> On Sun, Apr 05, 2015 at 12:45:00PM -0500, Alan Cox wrote:
>>> A> On 04/05/2015 10:47, Gleb Smirnoff wrote:
>>> A> > On Sun, Apr 05, 2015 at 06:37:58AM -0700, David Wolfskill wrote:
>>> A> > D> It ocurred rather late in the transition to multi-user mode, but
>>> A> > D> prior to starting xdm (on my laptop).
>>> A> > D> 
>>> A> > D> Previous (working) head/i386 for this machine was r281074.
>>> A> > D> 
>>> A> > D> Here's the first bit of the crashinfo (yes, I have a crash dump):
>>> A> > D> 
>>> A> > D> g1-254.catwhisker.org dumped core - see /var/crash/vmcore.3
>>> A> > D> 
>>> A> > D> Sun Apr  5 06:18:44 PDT 2015
>>> A> > D> 
>>> A> > 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     root_at_g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386
>>> A> > D> 
>>> A> > D> panic: Lock vm object not exclusively locked _at_ /usr/src/sys/vm/vm_page.c:2637
>>> A> >
>>> A> > This is r281079.
>>> A> >
>>> A> > Since vm_page_advise() may call vm_page_dirty() in the MADV_DONTNEED case,
>>> A> > the assertion is valid. So, looks like vm_fault_dontneed() needs W-lock on
>>> A> > the first_object.
>>> A> >
>>> A> 
>>> A> Actually, what I forgot was that vm_page_advise(MADV_FREE) clears the
>>> A> page's dirty field, and that is why an exclusive lock is asserted.  As
>>> A> explained in vm_page.h, the pmap is allowed to set the dirty field to
>>> A> all ones without any locking.  Moreover, the new "fast" path in
>>> A> vm_fault() sets the dirty field with only a read lock held. 
>>> A> vm_page_advise(MADV_DONTNEED) isn't really any different from the fast path.
>>> A> 
>>> A> Need to think a bit ...
>>>
>>> Can you please plug the panic somehow interim? For me the assert fires 100%
>>> reliably on any build attempt. Right now I changed vm_fault_dontneed() to
>>> take W-lock, so that I can continue running head. Not sure this is correct
>>> measure.
>>>
>> Just curious, amd64 or i386?
> Alan, this is caused by your r281079.  Are you working on it?  If you don't have a resolution soon, I think we should revert it ASAP as it's extremely easy to panic the system.

It was fixed about six hours ago: r281118.