Date: Thu, 20 Mar 2014 00:26:33 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Alan Cox <alc@rice.edu> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org> Subject: Re: svn commit: r263214 - in head/sys: compat/freebsd32 kern sys Message-ID: <20140320072633.GJ32089@funkthat.com> In-Reply-To: <5329C657.3000705@rice.edu> References: <201403160053.s2G0rfmA073668@svn.freebsd.org> <CAJ-Vmon9%2BNmJghpjwi1NB2k1ETc=bPJJSjQzL-TFVKLZHi8iiA@mail.gmail.com> <20140316012609.GY32089@funkthat.com> <5329C657.3000705@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Cox wrote this message on Wed, Mar 19, 2014 at 11:31 -0500:
> 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.
Looks like it's kmem_object:
$ /usr/armeb-freebsd/usr/bin/nm /tftpboot/kernel.avila.avila | grep object_store
c06d17d8 B kernel_object_store
c06d1878 B kmem_object_store
0xc06d18a0 (the listq->tqe_prev is in the kmem_object_store...
Probably the memq member...
I followed a link to another page, and it is also a kmem_object page,
and the other pages around it appear to be kmem_object...
> 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.
Interesting...
Deos this mean a page ended up on the incorrect list?
One thing I haven't tried is to run w/o INVARIANTS yet... obviously
that would get me farther, but hid the problem...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140320072633.GJ32089>