svn commit: r263214 - in head/sys: compat/freebsd32 kern sys

[John-Mark Gurney]

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."