Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

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?

(Kostik, by the way, I would be happy to see attribute flags added to
the vm object to take the place of the type checks.)


> I am curious, what was the process which caused the panic ?
>
> diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c
> index e19750c..5b8ed23 100644
> --- a/sys/vm/vm_object.c
> +++ b/sys/vm/vm_object.c
> _at__at_ -1060,7 +1060,10 _at__at_ shadowlookup:
>  			    (tobject->flags & OBJ_ONEMAPPING) == 0) {
>  				goto unlock_tobject;
>  			}
> -		} else if (tobject->type == OBJT_PHYS)
> +		} else if (tobject->type == OBJT_PHYS ||
> +		    tobject->type == OBJT_SG ||
> +		    tobject->type == OBJT_MGTDEVICE ||
> +		    tobject->type == OBJT_DEVICE)
>  			goto unlock_tobject;
>  		m = vm_page_lookup(tobject, tpindex);
>  		if (m == NULL && advise == MADV_WILLNEED) {