Date: Sun, 05 Apr 2015 17:49:15 -0700 From: Rui Paulo <rpaulo@me.com> To: Alan Cox <alc@rice.edu> Cc: alc@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, current@freebsd.org Subject: Re: panic: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:2637 Message-ID: <3A9C264F-3DAD-473B-A030-3FD026C2E8E3@me.com> In-Reply-To: <5521961C.8010808@rice.edu> References: <20150405133758.GA40261@albert.catwhisker.org> <20150405154721.GO64665@FreeBSD.org> <5521749C.4020408@rice.edu> <20150405193425.GR64665@glebius.int.ru> <5521961C.8010808@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 5, 2015, at 13:07, Alan Cox <alc@rice.edu> wrote:
>=20
> 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>=20
>> A> > D> Previous (working) head/i386 for this machine was r281074.
>> A> > D>=20
>> A> > D> Here's the first bit of the crashinfo (yes, I have a crash =
dump):
>> A> > D>=20
>> A> > D> g1-254.catwhisker.org dumped core - see /var/crash/vmcore.3
>> A> > D>=20
>> A> > D> Sun Apr 5 06:18:44 PDT 2015
>> A> > D>=20
>> 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@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386
>> A> > D>=20
>> A> > D> panic: Lock vm object not exclusively locked @ =
/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>=20
>> 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.=20
>> A> vm_page_advise(MADV_DONTNEED) isn't really any different from the =
fast path.
>> A>=20
>> A> Need to think a bit ...
>>=20
>> 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.
>>=20
>=20
> 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.
--
Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A9C264F-3DAD-473B-A030-3FD026C2E8E3>