Date: Wed, 9 Sep 2009 15:07:32 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Norbert Koch <nkoch@demig.de> Subject: Re: lock order reversal etc. Message-ID: <200909091507.32600.jhb@freebsd.org> In-Reply-To: <4AA7D4BA.40002@demig.de> References: <4AA7D4BA.40002@demig.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 09 September 2009 12:15:54 pm Norbert Koch wrote:
> Hello.
>
> Is this the right mailing list to post
> kernel stack traces from Freebsd-8-BETA4?
> If yes, see below, otherwise just ignore this message.
>
> uma_zalloc_arg: zone "64" with the following non-sleepable locks held:
> exclusive sleep mutex jail mutex (jail mutex) r = 0 (0xc0b91328) locked
> @
> /usr/src/sys/modules/syscons/daemon/../../../dev/syscons/daemon/daemon_saver.c:355
> KDB: stack backtrace:
> db_trace_self_wrapper(c0abf50f,e69b391c,c07ab3b5,c4a0580a,163,...) at
> db_trace_self_wrapper+0x26
> kdb_backtrace(c4a0580a,163,ffffffff,c0d261c4,e69b3954,...) at
> kdb_backtrace+0x29
> _witness_debugger(c0ac198e,e69b3968,4,1,0,...) at _witness_debugger+0x25
> witness_warn(5,0,c0ae4b92,c0add27b,e69b3984,...) at witness_warn+0x1fd
> uma_zalloc_arg(c148b000,0,2,2,14,...) at uma_zalloc_arg+0x34
> malloc(29,c0b92dd0,2,163,c46562e4,...) at malloc+0xe4
> daemon_init(c0d61940,c0aba83e,e69b3a28,c46f5600,c4a06cc0,...) at
> daemon_init+0x7b
> splash_test(7b,c46f5600,c4a06cc0,c46f5600,e69b3a50,...) at splash_test+0x91
> splash_register(c4a06c40,0,0,76,0,...) at splash_register+0x48
Try this patch for this one:
Index: daemon_saver.c
===================================================================
--- daemon_saver.c (revision 196974)
+++ daemon_saver.c (working copy)
@@ -351,11 +351,23 @@
static int
daemon_init(video_adapter_t *adp)
{
+ size_t hostlen;
mtx_lock(&prison0.pr_mtx);
- messagelen = strlen(prison0.pr_hostname) + 3 + strlen(ostype) + 1 +
- strlen(osrelease);
- message = malloc(messagelen + 1, M_DEVBUF, M_WAITOK);
+ for (;;) {
+ hostlen = strlen(prison0.pr_hostname);
+ mtx_unlock(&prison0.pr_mtx);
+
+ messagelen = hostlen + 3 + strlen(ostype) + 1 +
+ strlen(osrelease);
+ message = malloc(messagelen + 1, M_DEVBUF, M_WAITOK);
+ mtx_lock(&prison0.pr_mtx);
+ if (hostlen < strlen(prison0.pr_hostname)) {
+ free(message, M_DEVBUF);
+ continue;
+ }
+ break;
+ }
sprintf(message, "%s - %s %s", prison0.pr_hostname, ostype, osrelease);
mtx_unlock(&prison0.pr_mtx);
blanked = 0;
> lock order reversal:
> 1st 0xc4afca2c filedesc structure (filedesc structure) @
> /usr/src/sys/kern/kern_descrip.c:1088
> 2nd 0xc4be3488 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4091
> KDB: stack backtrace:
This is the right order. I think several of these have been fixed, but there
still might be some place that uses UFS -> filedesc. You can try hardcoding
that order into witness to find it.
> lock order reversal:
> 1st 0xd82d03f0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559
> 2nd 0xc4f64800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285
This is known to be harmless.
> lock order reversal:
> 1st 0xc464337c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083
> 2nd 0xd81d14b0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6177
> 3rd 0xc673a7ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083
> KDB: stack backtrace:
> db_trace_self_wrapper(c0abf50f,e6b103cc,c07ab3b5,c079c13b,c0ac23fb,...)
> at db_trace_self_wrapper+0x26
> kdb_backtrace(c079c13b,c0ac23fb,c4122e90,c4126290,e6b10428,...) at
> kdb_backtrace+0x29
> _witness_debugger(c0ac23fb,c673a7ac,c0ab4f66,c4126290,c0ac96be,...) at
> _witness_debugger+0x25
> witness_checkorder(c673a7ac,9,c0ac96be,823,0,...) at
> witness_checkorder+0x839
> __lockmgr_args(c673a7ac,80100,c673a7c8,0,0,...) at __lockmgr_args+0x7a7
> ffs_lock(e6b10538,c07ab15b,c0ac8bb1,80100,c673a754,...) at ffs_lock+0x8a
> VOP_LOCK1_APV(c0bae360,e6b10538,c4c08524,c0bc5660,c673a754,...) at
> VOP_LOCK1_APV+0xb5
> _vn_lock(c673a754,80100,c0ac96be,823,4,...) at _vn_lock+0x5e
> vget(c673a754,80100,c4c08480,50,0,...) at vget+0xb9
> vfs_hash_get(c46e1508,18ef074,80000,c4c08480,e6b10694,...) at
> vfs_hash_get+0xe6
> ffs_vgetf(c46e1508,18ef074,80000,e6b10694,1,...) at ffs_vgetf+0x49
> softdep_sync_metadata(c4643324,0,c0ae2efa,146,0,...) at
> softdep_sync_metadata+0x5ba
> ffs_syncvnode(c4643324,1,c0abaa2c,c0ab45da,3,...) at ffs_syncvnode+0x3e2
> ffs_truncate(c4643324,600,0,880,c465d280,...) at ffs_truncate+0x66a
> ufs_direnter(c4643324,c673a754,e6b10a1c,e6b10c00,d82ec1d0,...) at
> ufs_direnter+0x8f6
> ufs_mkdir(e6b10c28,e6b10c3c,0,0,e6b10b6c,...) at ufs_mkdir+0x8a7
> VOP_MKDIR_APV(c0bae360,e6b10c28,e6b10c00,e6b10b6c,0,...) at
> VOP_MKDIR_APV+0xa5
> kern_mkdirat(c4c08480,ffffff9c,804c2e8,0,41fd,...) at kern_mkdirat+0x22b
> kern_mkdir(c4c08480,804c2e8,0,41fd,e6b10d2c,...) at kern_mkdir+0x2e
> mkdir(c4c08480,e6b10cf8,8,c0ac2cbd,c0b8d920,...) at mkdir+0x29
> syscall(e6b10d38) at syscall+0x2a3
> Xint0x80_syscall() at Xint0x80_syscall+0x20
This is probably harmless.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200909091507.32600.jhb>