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

[Alan Cox]

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