Date: Fri, 26 Apr 2002 16:57:51 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Dag-Erling Smorgrav <des@ofug.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_witness.c Message-ID: <XFMail.20020426165751.jhb@FreeBSD.org> In-Reply-To: <xzphely2osl.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26-Apr-2002 Dag-Erling Smorgrav wrote:
> John Baldwin <jhb@FreeBSD.org> writes:
>> How do you test changes to the kernel w/o rebooting?
>
> I'm not currently working on the kernel.
Mutex profiling counts as kernel work I think. The problem was that
the original commit was not fully tested. However, bugfixes should
still be tested before they go in. Even having the submitter of the
bug report test the patch before it goes in is sufficient and doesn't
require you to reboot your own machine.
Well, since no one else tests this stuff, I decided to do so and voila:
# sysctl debug.mutex.prof
debug.mutex.prof.enable: 1
debug.mutex.prof.acquisitions: 165324
debug.mutex.prof.records: 157
debug.mutex.prof.maxrecords: 1000
debug.mutex.prof.rejected: 0
debug.mutex.profpani.hashsize: c1009
: blockable sleep lock (sleep mutex) PCPU 2048 @ ../../../vm/uma_core.c:1301
cpuid = 1; lapic.id = 01000000
Debugger("panic")
Stopped at Debugger+0x42: xorl %eax,%eax
db> t
Debugger(c02d7e5a) at Debugger+0x42
panic(c02db260,c02d6c20,cf98da00,c02efe11,515) at panic+0xd8
witness_lock(cf98db34,8,c02efe11,515) at witness_lock+0x85
_mtx_lock_flags(cf98db34,0,c02efe11,515,800) at _mtx_lock_flags+0x74
uma_zalloc_arg(cf98da00,0,0,d9c47040,54) at uma_zalloc_arg+0x37
malloc(800,c0312700,0,44a,d9c47040) at malloc+0x67
sbuf_extend(d9c47040,4a) at sbuf_extend+0x2a
sbuf_vprintf(d9c47040,c02d6fe0,db7ecb94,db7ecbd0,c01a8f89) at sbuf_vprintf+0x7e
sbuf_printf(d9c47040,c02d6fe0,a,0,262,0,76,0,5,0,c02d8413,82,c02d72a0) at
sbuf_printf+0x14
dump_mutex_prof_stats(c0310140,0,0,db7ecc20,0) at dump_mutex_prof_stats+0x115
sysctl_root(0,db7eccb8,4,db7ecc20,0) at sysctl_root+0x12c
userland_sysctl(db77c414,db7eccb8,4,0,bfbfeb5c) at userland_sysctl+0xed
__sysctl(db77c414,db7ecd20,0,bfbff3c8,4) at __sysctl+0x7d
syscall(2f,2f,2f,4,bfbff3c8) at syscall+0x227
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (202, FreeBSD ELF, __sysctl), eip = 0x80576cf, esp = 0xbfbfeacc,
ebp = 0xbfbfeb08 ---
db>
You can't be calling malloc while holding a spin lock. I would lock the
mutex, read the contents of an item from the array into stack variables,
unlock the mutex, then do the sbuf operation. I also suggest you _test_
this before committing the fix.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020426165751.jhb>