From owner-cvs-all Fri Apr 26 13:59: 0 2002 Delivered-To: cvs-all@freebsd.org Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by hub.freebsd.org (Postfix) with ESMTP id A6AF537B405 for ; Fri, 26 Apr 2002 13:58:44 -0700 (PDT) Received: (qmail 23032 invoked from network); 26 Apr 2002 20:58:43 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Apr 2002 20:58:43 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g3QKwfv15649; Fri, 26 Apr 2002 16:58:42 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 26 Apr 2002 16:57:51 -0400 (EDT) From: John Baldwin To: Dag-Erling Smorgrav Subject: Re: cvs commit: src/sys/kern subr_witness.c Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 26-Apr-2002 Dag-Erling Smorgrav wrote: > John Baldwin 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 <>< 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