From owner-freebsd-current@FreeBSD.ORG Tue Sep 21 00:04:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21E3A16A4CE for ; Tue, 21 Sep 2004 00:04:19 +0000 (GMT) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74DBB43D46 for ; Tue, 21 Sep 2004 00:04:18 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with ESMTP id i8L04EqR025471 for ; Tue, 21 Sep 2004 01:04:14 +0100 (BST) Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.12.9p2/8.12.9) with ESMTP id i8L044Mu026739 for ; Tue, 21 Sep 2004 01:04:04 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost)i8L03xUh026736 for ; Tue, 21 Sep 2004 01:04:04 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Tue, 21 Sep 2004 01:03:59 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: current@freebsd.org Message-ID: <20040921005321.O26587@ury.york.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Subject: NFS Mbuf malloc(M_WAITOK) with locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2004 00:04:19 -0000 Hi all, I'm seeing the following two code paths leading to a malloc with locks held on a 5.3-BETA2 machine which is both an NFS server and an NFS client... malloc(M_WAITOK) of "Mbuf", forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex nfsd_mtx r = 0 (0xc08eed00) locked @ /usr/src/sys/nfsserver/nfs_srvsock.c:712 KDB: stack backtrace: kdb_backtrace(1,1,1,1a,c101fb00) at kdb_backtrace+0x29 witness_warn(5,0,c0809b40,c07ef018,0) at witness_warn+0x19a uma_zalloc_arg(c101fb00,dc799bec,2) at uma_zalloc_arg+0x41 nfsm_disct(dc799c38,dc799c3c,28,0,c1d38c00) at nfsm_disct+0xa2 nfsm_dissect_xx(28,dc799c38,dc799c3c) at nfsm_dissect_xx+0x31 nfs_getreq(c2a88e00,c1881000,1,c08eed00,0) at nfs_getreq+0x49 nfsrv_dorec(c1acb300,c1881000,dc799cac,dc799ca4,0) at nfsrv_dorec+0xc3 nfssvc_nfsd(c16336e0,c07efaa5,121,c175406c,c1754000) at nfssvc_nfsd+0x1df nfssvc(c16336e0,dc799d14,2,0,296) at nfssvc+0x18c syscall(2f,2f,2f,bfbfeec4,4) at syscall+0x217 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (155, FreeBSD ELF32, nfssvc), eip = 0x280cbb87, esp = 0xbfbfeb1c, ebp = 0xbfbfeb38 --- and malloc(M_WAITOK) of "Mbuf", forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex nfsd_mtx r = 0 (0xc08eed00) locked @ /usr/src/sys/nfsserver/nfs_serv.c:1103 KDB: stack backtrace: kdb_backtrace(1,1,1,d,c101fb00) at kdb_backtrace+0x29 witness_warn(5,0,c0809b40,c07ef018,dc799a2c) at witness_warn+0x19a uma_zalloc_arg(c101fb00,dc799a3c,2) at uma_zalloc_arg+0x41 nfsm_disct(dc799ac4,dc799ac8,14,d,46) at nfsm_disct+0xa2 nfsm_dissect_xx(14,dc799ac4,dc799ac8) at nfsm_dissect_xx+0x31 nfsrv_write(c1915d00,c1acb300,c16336e0,dc799ca8,dc799ca4) at nfsrv_write+0x1e2 nfssvc_nfsd(c16336e0,c07efaa5,121,c175406c,c1754000) at nfssvc_nfsd+0x3d5 nfssvc(c16336e0,dc799d14,2,0,296) at nfssvc+0x18c syscall(2f,2f,2f,bfbfeec4,4) at syscall+0x217 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (155, FreeBSD ELF32, nfssvc), eip = 0x280cbb87, esp = 0xbfbfeb1c, ebp = 0xbfbfeb38 --- /usr/src/sys/nfsserver/nfs_serv.c: $FreeBSD: src/sys/nfsserver/nfs_serv.c,v 1.147 2004/06/17 17:16:52 phk Exp $ /usr/src/sys/nfsserver/nfs_srvsock.c: $FreeBSD: src/sys/nfsserver/nfs_srvsock.c,v 1.92 2004/07/24 02:07:09 While some locking related changes went into nfs_serv.c 1.148, as far as I can see they don't affect the code path I'm seeing (and only touched Giant locking, whereas I'm seeing issues relating to nfsd_mtx). Regardless, I'll take this machine to current RELENG_5 and see if I still see the messages. Gavin