Re: Early drop to debugger with DEBUG_MEMGUARD

From: Davide Italiano <davide_at_freebsd.org>
Date: Mon, 12 Aug 2013 09:10:55 -0700
On Mon, Aug 12, 2013 at 9:01 AM, David Wolfskill <david_at_catwhisker.org> wrote:
> On Mon, Aug 12, 2013 at 08:30:15AM -0700, Davide Italiano wrote:
>> ...
>> > Booting...
>> > GDB: no debug ports present
>> > KDB: debugger backends: ddb
>> > KDB: current backend: ddb
>> > Copyright (c) 1992-2013 The FreeBSD Project.
>> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>> >         The Regents of the University of California. All rights reserved.
>> > FreeBSD is a registered trademark of The FreeBSD Foundation.
>> > FreeBSD 10.0-CURRENT #0  r254245M/254246:1000042: Mon Aug 12 07:20:47 PDT 2013
>> >     root_at_freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
>> > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>> > WARNING: WITNESS option enabled, expect reduced performance.
>> > panic: Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at /usr/src/sys/kern/subr_vmem.c:1050
>> > cpuid = 0
>> > KDB: stack backtrace:
>> > db_trace_self_wrapper(c116fcdc,73752f20,72732f72,79732f63,656b2f73,...) at db_trace_self_wrapper+0x2d/frame 0xc1820ba0
>> > kdb_backtrace(c11c4b23,0,c0f8a835,c1820c74,c0f8a835,...) at kdb_backtrace+0x30/frame 0xc1820c08
>> > vpanic(c12eea08,100,c0f8a835,c1820c74,c1820c74,...) at vpanic+0x11f/frame 0xc1820c44
>> > kassert_panic(c0f8a835,c1172e98,c1172e39,41a,8,...) at kassert_panic+0xea/frame 0xc1820c68
>> > vmem_alloc(c130d680,6681000,2,c1820cc0,3b5,...) at vmem_alloc+0x53/frame 0xc1820ca0
>> > memguard_init(c130d680,c0a9fa50,c6800000,20281000,1000,10000,0) at memguard_init+0x29/frame 0xc1820cc4
>> > kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame 0xc1820cf0
>> > mallocinit(0,0,2,0,c11d3728,...) at mallocinit+0x32/frame 0xc1820d30
>> > mi_startup() at mi_startup+0xf7/frame 0xc1820d58
>> > begin() at begin+0x2c
>> > KDB: enter: panic
>> > [ thread pid 0 tid 0 ]
>> > Stopped at      kdb_enter+0x3d: movl    $0,kdb_why
>> > db>
>> >
>> > As you can see, this is well before any device probes or much of
>> > anything else.  Thus, I suspect that it's fairly possible that the
>> > assertion may well be OK after a certain point in the boot sequence,
>> > but decidedly *not* OK in this specific instance.  Or perhaps the
>> > assertion just doesn't play well with DEBUG_MEMGUARD.
>> ...
>
>> vmem_alloc() KPI needs the consumer to specify exactly a strategy for
>> allocation, which is one of two between: M_FIRSTFIT/M_BESTFIT (fast
>> allocation vs low fragmentation), and that's the assertion that's not
>> respected within the code.
>>
>> 1050          MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT);
>>
>> It looks like memguard_init() doesn't specify none of these two strategies.
>>
>> 209           vmem_alloc(parent, memguard_mapsize, M_WAITOK, &base);
>>
>> My guess is that you need to OR one between M_BESTFIT/M_FIRSTFIT with
>> M_WAITOK to have your kernel booting. What's better between the two
>> probably will need some measurements but this should at least make
>> your kernel booting.
>
> Thank you for the insight & suggestion.
>
> My first attempt was to make the following change:
>
> Index: sys/vm/memguard.c
> ===================================================================
> --- sys/vm/memguard.c   (revision 254246)
> +++ sys/vm/memguard.c   (working copy)
> _at__at_ -206,9 +206,9 _at__at_
>  {
>         vm_offset_t base;
>
> -       vmem_alloc(parent, memguard_mapsize, M_WAITOK, &base);
> +       vmem_alloc(parent, memguard_mapsize, M_WAITOK | M_FIRSTFIT, &base);
>         memguard_map = vmem_create("memguard arena", base, memguard_mapsize,
> -           PAGE_SIZE, 0, M_WAITOK);
> +           PAGE_SIZE, 0, M_WAITOK | M_FIRSTFIT);
>         memguard_cursor = base;
>         memguard_base = base;
>
> This built OK; but attempting to boot yielded:
>
> Booting...
> GDB: no debug ports present
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 10.0-CURRENT #1  r254245M/254246:1000042: Mon Aug 12 08:49:12 PDT 2013
>     root_at_freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> WARNING: WITNESS option enabled, expect reduced performance.
> panic: mti_zone 195 out of range 8
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper(c116fcdc,0,ffffffff,c1167d73,fffffffe,...) at db_trace_self_wrapper+0x2d/frame 0xc1820b58
> kdb_backtrace(c11c4b23,0,c1167d58,c1820c30,c1820c00,...) at kdb_backtrace+0x30/frame 0xc1820bc0
> vpanic(c12eea08,100,c1167d58,c1820c30,c1820c30,...) at vpanic+0x11f/frame 0xc1820c00
> kassert_panic(c1167d58,c3,8,c130d7e4,c130d7a8,...) at kassert_panic+0xea/frame 0xc1820c24
> malloc(380,c1279778,2,0,ffffffff,...) at malloc+0x308/frame 0xc1820c70
> vmem_create(c11a7530,c6800000,6681000,1000,0,...) at vmem_create+0x29/frame 0xc1820ca0
> memguard_init(c130d680,c0a9fa50,c6800000,20281000,1000,10000,0) at memguard_init+0x5e/frame 0xc1820cc4
> kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame 0xc1820cf0
> mallocinit(0,0,2,0,c11d3728,...) at mallocinit+0x32/frame 0xc1820d30
> mi_startup() at mi_startup+0xf7/frame 0xc1820d58
> begin() at begin+0x2c
> KDB: enter: panic
> [ thread pid 0 tid 0 ]
> Stopped at      kdb_enter+0x3d: movl    $0,kdb_why
> db>
>
>
> grepping through the sources indicates to me that I/we have run afoul of:
>
> ./kern/kern_malloc.c-504-               if (size & KMEM_ZMASK)
> ./kern/kern_malloc.c-505-                       size = (size & ~KMEM_ZMASK) + KMEM_ZBASE;
> ./kern/kern_malloc.c-506-               indx = kmemsize[size >> KMEM_ZSHIFT];
> ./kern/kern_malloc.c:507:               KASSERT(mtip->mti_zone < numzones,
> ./kern/kern_malloc.c:508:                   ("mti_zone %u out of range %d",
> ./kern/kern_malloc.c:509:                   mtip->mti_zone, numzones));
> ./kern/kern_malloc.c:510:               zone = kmemzones[indx].kz_zone[mtip->mti_zone];
> ./kern/kern_malloc.c-511-#ifdef MALLOC_PROFILE
> ./kern/kern_malloc.c-512-               krequests[size >> KMEM_ZSHIFT]++;
> ./kern/kern_malloc.c-513-#endif
>
> Hmm....
>
> Peace,
> david
> --
> David H. Wolfskill                              david_at_catwhisker.org
> Taliban: Evil men with guns afraid of truth from a 14-year old girl.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.

OK, I'm not sure I can make an immediate guess on where's the problem
now (without access to my main workstation), so I think you need to
wait tomorrow unless someone beats me to the punch. The best I can say
is that maybe r254025 is responsible for this. Try to revert and see
if things work again.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
Received on Mon Aug 12 2013 - 14:10:56 UTC

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