From owner-freebsd-current@FreeBSD.ORG Mon Apr 6 00:49:28 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F9D72C3; Mon, 6 Apr 2015 00:49:28 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11A28689; Mon, 6 Apr 2015 00:49:27 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NMD00KE50Y3KE20@st11p02mm-asmtp002.mac.com>; Mon, 06 Apr 2015 00:49:18 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-05_03:2015-04-03,2015-04-05,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504060006 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: panic: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:2637 From: Rui Paulo In-reply-to: <5521961C.8010808@rice.edu> Date: Sun, 05 Apr 2015 17:49:15 -0700 Content-transfer-encoding: quoted-printable Message-id: <3A9C264F-3DAD-473B-A030-3FD026C2E8E3@me.com> References: <20150405133758.GA40261@albert.catwhisker.org> <20150405154721.GO64665@FreeBSD.org> <5521749C.4020408@rice.edu> <20150405193425.GR64665@glebius.int.ru> <5521961C.8010808@rice.edu> To: Alan Cox X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Mon, 06 Apr 2015 01:01:19 +0000 Cc: alc@FreeBSD.org, Gleb Smirnoff , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 00:49:28 -0000 On Apr 5, 2015, at 13:07, Alan Cox 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