Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

From: Alan Cox <alc_at_rice.edu>
Date: Tue, 27 Nov 2012 12:27:42 -0600
On 11/27/2012 12:08, Andre Oppermann wrote:
> On 27.11.2012 17:42, Alan Cox wrote:
>> On 11/27/2012 09:06, Konstantin Belousov wrote:
>>> On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
>>>> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
>>>> Fri Nov 23 17:00:40 CET 2012
>>>> aaa_at_bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64
>>>>
>>>> #0  doadump (textdump=-2014022336) at pcpu.h:229
>>>> #1  0xffffffff8033e2d2 in db_fncall (dummy1=<value optimized out>,
>>>> dummy2=<value optimized out>,
>>>>       dummy3=<value optimized out>, dummy4=<value optimized out>)
>>>>       at /usr/src/head/sys/ddb/db_command.c:578
>>>> #2  0xffffffff8033e074 in db_command (last_cmdp=<value optimized out>,
>>>>       cmd_table=<value optimized out>, dopager=1) at
>>>> /usr/src/head/sys/ddb/db_command.c:449
>>>> #3  0xffffffff8033dd62 in db_command_loop () at
>>>> /usr/src/head/sys/ddb/db_command.c:502
>>>> #4  0xffffffff80340690 in db_trap (type=<value optimized out>, code=0)
>>>>       at /usr/src/head/sys/ddb/db_main.c:231
>>>> #5  0xffffffff808b375e in kdb_trap (type=3, code=0, tf=<value
>>>> optimized
>>>> out>)
>>>>       at /usr/src/head/sys/kern/subr_kdb.c:654
>>>> #6  0xffffffff80bfc71a in trap (frame=0xffffff8487f478a0)
>>>>       at /usr/src/head/sys/amd64/amd64/trap.c:579
>>>> #7  0xffffffff80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
>>>> #8  0xffffffff808b2f5e in kdb_enter (why=0xffffffff80e5e23b "panic",
>>>> msg=<value optimized out>)
>>>>       at cpufunc.h:63
>>>> #9  0xffffffff8088086f in panic (fmt=<value optimized out>)
>>>>       at /usr/src/head/sys/kern/kern_shutdown.c:628
>>>> #10 0xffffffff80adea4a in vm_object_madvise (object=<value
>>>> optimized out>,
>>>>       pindex=<value optimized out>, end=8952, advise=<value
>>>> optimized out>)
>>>>       at /usr/src/head/sys/vm/vm_object.c:1101
>>>> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188,
>>>> start=<value optimized out>,
>>>>       end=<value optimized out>, behav=5) at
>>>> /usr/src/head/sys/vm/vm_map.c:2140
>>>> #12 0xffffffff80adbd8d in sys_madvise (td=<value optimized out>,
>>>> uap=<value optimized out>)
>>>>       at /usr/src/head/sys/vm/vm_mmap.c:752
>>>> #13 0xffffffff80bfd3a5 in amd64_syscall (td=0xfffffe0018230000,
>>>> traced=0) at subr_syscall.c:135
>>>> #14 0xffffffff80be689b in Xfast_syscall () at
>>>> /tmp/exception-3nQ6Cf.s:329
>>>> #15 0x00000000016f3bfa in ?? ()
>>> I think this is an omission in the check for the object types. BTW,
>>> this
>>> pattern already repeats in several places, I thought about adding
>>> either
>>> new pager method, like boolean_t vm_pager_is_pageable(), or just a flag
>>> fields to the struct vm_pager to classify the vm objects.
>>
>>
>> A fictitious page should always have a non-zero wire count.  In fact, it
>> should always be one and never change.  (See vm_page_unwire().)  In
>> vm_object_madvise(), there is a check against the page's wire count that
>> precedes the KASSERT().  This check should prevent the KASSERT() from
>> being reached for the various device-backed object types.  So, something
>> else has gone wrong here, or rather something has gone wrong elsewhere
>> that caused the KASSERT() failure here.
>>
>> Andre, can we see the contents of the offending struct vm_page and also
>> the struct vm_object to which the offending page belongs to?  Also, are
>> you running a kernel with any experimental zero-copy send support?
>
> No experimental zero-copy support, or anything else, just a stock
> GENERIC kernel.
>
> (kgdb) frame 11
> #11 0xffffffff80ad759a in vm_map_madvise (map=0xfffffe0018260188,
> start=<value optimized out>,
>     end=<value optimized out>, behav=5) at
> /usr/src/head/sys/vm/vm_map.c:2140
> 2140                           
> vm_object_madvise(current->object.vm_object, pstart,
> (kgdb) p *map
> $1 = {header = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8,
> left = 0x0, right = 0x0,
>     start = 4096, end = 140737488355328, avail_ssize = 0, adj_free =
> 0, max_free = 0, object = {
>       vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0,
> protection = 0 '\0',
>     max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0
> '\0', wired_count = 0,
>     next_read = 0, cred = 0x0}, lock = {lock_object = {
>       lo_name = 0xffffffff80e66905 "vm map (user)", lo_flags =
> 36896768, lo_data = 0,
>       lo_witness = 0xffffff80006c9700}, sx_lock = 17}, system_mtx =
> {lock_object = {
>       lo_name = 0xffffffff80e668d7 "vm map (system)", lo_flags =
> 21168128, lo_data = 0,
>       lo_witness = 0xffffff80006c9500}, mtx_lock = 4}, nentries = 32,
> size = 64647168,
>   timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags =
> 0 '\0',
>   root = 0xfffffe02560a6258, pmap = 0xfffffe00182602b8, busy = 0}
> (kgdb) p* map->pmap
> $6 = {pm_mtx = {lock_object = {lo_name = 0xffffffff80e66934 "pmap",
> lo_flags = 21168128,
>       lo_data = 0, lo_witness = 0xffffff80006c9900}, mtx_lock = 4},
> pm_pml4 = 0xfffffe0256458000,
>   pm_pvchunk = {tqh_first = 0xfffffe0256142000, tqh_last =
> 0xfffffe025644c008}, pm_active = {
>     __bits = {1}}, pm_stats = {resident_count = 12683, wired_count = 0},
>   pm_root = 0xfffffe041289e040}
> (kgdb) p* map->root
> $7 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left =
> 0xfffffe0018ed0708,
>   right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536,
> avail_ssize = 0,
>   adj_free = 140703057047552, max_free = 140703057047552, object = {
>     vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570},
> offset = 1810432, eflags = 0,
>   protection = 3 '\003', max_protection = 7 '\a', inheritance = 1
> '\001', read_ahead = 15 '\017',
>   wired_count = 0, next_read = 0, cred = 0x0}
>
> (kgdb) p *current
> $2 = {prev = 0xfffffe025631c438, next = 0xfffffe0248f119d8, left =
> 0x0, right = 0x0, start = 4096,
>   end = 140737488355328, avail_ssize = 0, adj_free = 0, max_free = 0,
> object = {vm_object = 0x0,
>     sub_map = 0x0}, offset = 0, eflags = 0, protection = 0 '\0',
> max_protection = 0 '\0',
>   inheritance = 0 '\0', read_ahead = 0 '\0', wired_count = 0,
> next_read = 0, cred = 0x0}
>
> (kgdb) p *entry
> $3 = {prev = 0xfffffe0018ed0708, next = 0xfffffe02560a6870, left =
> 0xfffffe0018ed0708,
>   right = 0xfffffe02560a6870, start = 34393292800, end = 34431041536,
> avail_ssize = 0,
>   adj_free = 140703057047552, max_free = 140703057047552, object = {
>     vm_object = 0xfffffe0256484570, sub_map = 0xfffffe0256484570},
> offset = 1810432, eflags = 0,
>   protection = 3 '\003', max_protection = 7 '\a', inheritance = 1
> '\001', read_ahead = 15 '\017',
>   wired_count = 0, next_read = 0, cred = 0x0}


The following tells us that this is an OBJT_DEFAULT (i.e., anonymous)
memory object.  Such objects should never contain fictitious pages.  Can
you please print the contents of the offending struct vm_page using the
address from the panic message?


> (kgdb) p *entry->object.vm_object
> $4 = {mtx = {lock_object = {lo_name = 0xffffffff80e66913 "vm object",
> lo_flags = 21168128,
>       lo_data = 0, lo_witness = 0xffffff80006cdd00}, mtx_lock =
> 18446741875091243008},
>   object_list = {tqe_next = 0xfffffe0248ffb910, tqe_prev =
> 0xfffffe025618e020}, shadow_head = {
>     lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0x0},
> memq = {
>     tqh_first = 0xfffffe0413891880, tqh_last = 0xfffffe0413a3a570},
> root = 0xfffffe0413c58630,
>   size = 9658, generation = 1, ref_count = 1, shadow_count = 0,
> memattr = 6 '\006', type = 0 '\0',
>   flags = 12288, pg_color = 7750, paging_in_progress = 0,
> resident_page_count = 7650,
>   backing_object = 0x0, backing_object_offset = 0, pager_object_list =
> {tqe_next = 0x0,
>     tqe_prev = 0x0}, rvq = {lh_first = 0xfffffe0400ff07c0}, cache =
> 0x0, handle = 0x0, un_pager = {
>     vnp = {vnp_size = 0, writemappings = 0}, devp = {devp_pglist =
> {tqh_first = 0x0,
>         tqh_last = 0x0}, ops = 0x0}, sgp = {sgp_pglist = {tqh_first =
> 0x0, tqh_last = 0x0}},
>     swp = {swp_bcount = 0}}, cred = 0xfffffe0018244c00, charge =
> 39559168}
> (kgdb) p *entry->object.sub_map
> $5 = {header = {prev = 0xffffffff80e66913, next = 0x1430000, left =
> 0xffffff80006cdd00,
>     right = 0xfffffe0018230000, start = 18446741884500949264, end =
> 18446741884720701472,
>     avail_ssize = 0, adj_free = 0, max_free = 0, object = {vm_object =
> 0xfffffe0413891880,
>       sub_map = 0xfffffe0413891880}, offset = -2181513894544, eflags =
> 331712048,
>     protection = 4 '\004', max_protection = 254 'þ', inheritance = -1
> 'ÿ', read_ahead = 255 'ÿ',
>     wired_count = 9658, next_read = 4294967297, cred =
> 0x3000000600000000}, lock = {lock_object = {
>       lo_name = 0x1e46 <Address 0x1e46 out of bounds>, lo_flags =
> 7650, lo_data = 0,
>       lo_witness = 0x0}, sx_lock = 0}, system_mtx = {lock_object =
> {lo_name = 0x0, lo_flags = 0,
>       lo_data = 0, lo_witness = 0xfffffe0400ff07c0}, mtx_lock = 0},
> nentries = 0, size = 0,
>   timestamp = 0, needs_wakeup = 0 '\0', system_map = 0 '\0', flags = 0
> '\0', root = 0x0,
>   pmap = 0xfffffe0018244c00, busy = 39559168}
> (kgdb) p *entry->object.sub_map->pmap
> $8 = {pm_mtx = {lock_object = {lo_name = 0x3e900000114 <Address
> 0x3e900000114 out of bounds>,
>       lo_flags = 1001, lo_data = 1001, lo_witness = 0x3e900000003},
> mtx_lock = 1001},
>   pm_pml4 = 0xfffffe0018e53c00, pm_pvchunk = {tqh_first =
> 0xfffffe0018e53c00,
>     tqh_last = 0xffffffff811e74a0}, pm_active = {__bits =
> {-2198902153216}}, pm_stats = {
>     resident_count = 0, wired_count = 0}, pm_root = 0x0}
>
Received on Tue Nov 27 2012 - 17:35:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC