From owner-freebsd-current@FreeBSD.ORG Sun Apr 5 20:17:52 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 4837E25D; Sun, 5 Apr 2015 20:17:52 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C32E8923; Sun, 5 Apr 2015 20:17:51 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t35KHiqf086789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Apr 2015 23:17:44 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t35KHiAM086788; Sun, 5 Apr 2015 23:17:44 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 5 Apr 2015 23:17:44 +0300 From: Gleb Smirnoff To: Alan Cox Subject: Re: panic: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:2637 Message-ID: <20150405201744.GV64665@glebius.int.ru> References: <20150405133758.GA40261@albert.catwhisker.org> <20150405154721.GO64665@FreeBSD.org> <5521749C.4020408@rice.edu> <20150405193425.GR64665@glebius.int.ru> <5521961C.8010808@rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5521961C.8010808@rice.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: alc@FreeBSD.org, 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: Sun, 05 Apr 2015 20:17:52 -0000 On Sun, Apr 05, 2015 at 03:07:56PM -0500, Alan Cox wrote: A> On 04/05/2015 14:34, Gleb Smirnoff wrote: A> > On Sun, Apr 05, 2015 at 12:45:00PM -0500, Alan Cox wrote: A> > A> On 04/05/2015 10:47, Gleb Smirnoff wrote: A> > A> > On Sun, Apr 05, 2015 at 06:37:58AM -0700, David Wolfskill wrote: A> > A> > D> It ocurred rather late in the transition to multi-user mode, but A> > A> > D> prior to starting xdm (on my laptop). A> > A> > D> A> > A> > D> Previous (working) head/i386 for this machine was r281074. A> > A> > D> A> > A> > D> Here's the first bit of the crashinfo (yes, I have a crash dump): A> > A> > D> A> > A> > D> g1-254.catwhisker.org dumped core - see /var/crash/vmcore.3 A> > A> > D> A> > A> > D> Sun Apr 5 06:18:44 PDT 2015 A> > A> > D> A> > 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> > A> > D> A> > A> > D> panic: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:2637 A> > A> > A> > A> > This is r281079. A> > A> > A> > A> > Since vm_page_advise() may call vm_page_dirty() in the MADV_DONTNEED case, A> > A> > the assertion is valid. So, looks like vm_fault_dontneed() needs W-lock on A> > A> > the first_object. A> > A> > A> > A> A> > A> Actually, what I forgot was that vm_page_advise(MADV_FREE) clears the A> > A> page's dirty field, and that is why an exclusive lock is asserted. As A> > A> explained in vm_page.h, the pmap is allowed to set the dirty field to A> > A> all ones without any locking. Moreover, the new "fast" path in A> > A> vm_fault() sets the dirty field with only a read lock held. A> > A> vm_page_advise(MADV_DONTNEED) isn't really any different from the fast path. A> > A> A> > A> Need to think a bit ... A> > A> > Can you please plug the panic somehow interim? For me the assert fires 100% A> > reliably on any build attempt. Right now I changed vm_fault_dontneed() to A> > take W-lock, so that I can continue running head. Not sure this is correct A> > measure. A> > A> A> Just curious, amd64 or i386? Panics on amd64...., while building a kernel for i386, if that matters :) -- Totus tuus, Glebius.