Date: Wed, 19 Mar 2014 11:31:19 -0500 From: Alan Cox <alc@rice.edu> To: John-Mark Gurney <jmg@funkthat.com>, Adrian Chadd <adrian@freebsd.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r263214 - in head/sys: compat/freebsd32 kern sys Message-ID: <5329C657.3000705@rice.edu> In-Reply-To: <20140316012609.GY32089@funkthat.com> References: <201403160053.s2G0rfmA073668@svn.freebsd.org> <CAJ-Vmon9%2BNmJghpjwi1NB2k1ETc=bPJJSjQzL-TFVKLZHi8iiA@mail.gmail.com> <20140316012609.GY32089@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/15/2014 20:26, John-Mark Gurney wrote:
> Adrian Chadd wrote this message on Sat, Mar 15, 2014 at 18:17 -0700:
>> How far along does it get?
> It rarely gets to multiuser, and even if it does, it panics very
> shortly afterward:
> panic: vm_page_alloc: page 0xc0805db0 is wired
>
> I did finally get around to dumping the vm_page struct for it (the
> CTF crazyness) and I did send it to alc and kib, but neither one has
> replied...
>
> here is a dump in case someone else has some vm_page clue:
> {'act_count': '\x00',
> 'aflags': '\x00',
> 'busy_lock': 1,
> 'dirty': '\xff',
> 'flags': 0,
> 'hold_count': 0,
> 'listq': {'tqe_next': 0xc0805e00, 'tqe_prev': 0xc06d18a0},
> 'md': {'pv_kva': 3235856384,
> 'pv_list': {'tqh_first': 0x0, 'tqh_last': 0xc0805de0},
> 'pv_memattr': '\x00',
> 'pvh_attrs': 0},
> 'object': 0xc06d1878,
> 'oflags': '\x04',
> 'order': '\t',
> 'phys_addr': 17776640,
> 'pindex': 3572,
> 'plinks': {'memguard': {'p': 0, 'v': 3228376932},
> 'q': {'tqe_next': 0x0, 'tqe_prev': 0xc06d1f64},
> 's': {'pv': 0xc06d1f64, 'ss': {'sle_next': 0x0}}},
> 'pool': '\x00',
> 'queue': '\xff',
> 'segind': '\x01',
> 'valid': '\xff',
> 'wire_count': 1}
>
> and as you can see, wire_count is not 0... but looks resonable...
There are several things wrong with this page.
Two lines later, this assertion would also fail:
KASSERT(m->dirty == 0, ("vm_page_alloc: page %p is dirty", m));
because a page in the cache/free lists should never be dirty.
The page's flags field doesn't include PG_CACHED. So, the object field
should be NULL and the valid field should be 0, but they are not.
All of these fields are (explicitly) cleared when a page is freed (cf.
vm_page_free_toq()).
Can you determine if the value of the object field matches the address
of either kernel_object or kmem_object? The oflags field containing
VPO_UNMANAGED makes that likely.
In a nutshell, this looks like the same page is simultaneously in use by
one part of the kernel and free in another part. I doubt that it's a
simple case of use after free. In that case, the dirty, object, and
valid fields would be zero, and the crash would be in a different part
of the kernel.
> So, I'm blocked until someone w/ clue tells me what more I need to do
> to debug this...
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5329C657.3000705>