Re: mutex lock assertion panic in vm_page_free() on sparc64

From: Jung-uk Kim <jkim_at_niksun.com>
Date: Tue, 22 Feb 2005 14:22:56 -0500
On Tuesday 22 February 2005 02:09 pm, Alan Cox wrote:
> On Tue, Feb 22, 2005 at 04:27:11PM +0200, Ruslan Ermilov wrote:
> > On Tue, Feb 22, 2005 at 01:03:18PM +0200, Ruslan Ermilov wrote:
> > > Hi,
> > >
> > > I'm repeatedly getting the following panic (three-four times a
> > > day) on sparc64 running a fresh -CURRENT, building world:
> > >
> > > db> show msgbuf
> > > panic: mutex vm object not owned at
> > > /usr/src/sys/vm/vm_page.c:608 cpuid = 0
> > > KDB: enter: panic
> > > exclusive sleep mutex vm page queue mutex r = 0 (0xc04be700)
> > > locked _at_ /usr/src/sys/sparc64/sparc64/vm_machdep.c:483
> > > exclusive sleep mutex UMA lock r = 0 (0xc04bdcc0) locked _at_
> > > /usr/src/sys/vm/uma_core.c:1485 exclusive sleep mutex Giant r =
> > > 0 (0xc0422728) locked _at_ /usr/src/sys/vm/vm_pageout.c:666 db>
> > > where
> > > Tracing pid 7 tid 100016 td 0xfffff80067c0c720
> > > panic() at panic+0x16c
> > > _mtx_assert() at _mtx_assert+0x6c
> > > vm_page_remove() at vm_page_remove+0x34
> > > vm_page_free_toq() at vm_page_free_toq+0xb8
> > > vm_page_free() at vm_page_free+0x10
> > > uma_small_free() at uma_small_free+0x54
> > > zone_drain() at zone_drain+0x2e8
> > > zone_foreach() at zone_foreach+0x3c
> > > uma_reclaim() at uma_reclaim+0x10
> > > vm_pageout_scan() at vm_pageout_scan+0x13c
> > > vm_pageout() at vm_pageout+0x3e8
> > > fork_exit() at fork_exit+0x9c
> > > fork_trampoline() at fork_trampoline+0x8
> >
> > I have no idea if this is the correct fix or not, but the
> > necessary vm_object_t locking is certainly missing in
> > uma_small_free() on all architectures implementing it (alpha,
> > amd64, ia64, powerpc, and sparc64).
>
> It is not.  Take a look at uma_small_alloc().  You'll see that
> pages are allocated with the option VM_ALLOC_NOOBJ, meaning that
> they are not members of any vm object.  Consequently, the page's
> object field should remain NULL and vm_page_remove() should never
> be executed.  I'm afraid that something is trashing your
> vm_page_array.  Could you print the contents of the offending page
> structure?

FYI, anholt says 'backing vm/uma_core.c to r1.114 has fixed the 
issue':

http://docs.freebsd.org/cgi/mid.cgi?1109089389.4267.7.camel

Jung-uk Kim

> Alan
Received on Tue Feb 22 2005 - 18:23:05 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:28 UTC