From owner-freebsd-hackers Tue Sep 3 15: 6:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4799D37B400 for ; Tue, 3 Sep 2002 15:06:43 -0700 (PDT) Received: from host213-120-100-207.in-addr.btopenworld.com (host213-120-100-207.in-addr.btopenworld.com [213.120.100.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id C183243E42 for ; Tue, 3 Sep 2002 15:06:42 -0700 (PDT) (envelope-from dom@host213-120-100-207.in-addr.btopenworld.com) Received: by host213-120-100-207.in-addr.btopenworld.com (Postfix, from userid 1001) id 200C225B; Tue, 3 Sep 2002 23:06:56 +0100 (BST) Date: Tue, 3 Sep 2002 23:06:55 +0100 From: Dominic Marks To: freebsd-hackers@freebsd.org Subject: network interface lock order reversal question Message-ID: <20020903220655.GA1545@gallium> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hey, Just put -CURRENT back on an AMD Athlon machine I have after a three or four month absense, looking through dmesg I see the following: vr0: port 0xd400-0xd4ff mem 0xd8000000-0xd80000ff irq 11 at device 9.0 on pci0 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 lock order reversal 1st 0xc2667a90 vr0 (network driver) @ /usr/src/sys/pci/if_vr.c:659 2nd 0xc0488140 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:317 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 >> /usr/src/sys/pci/if_vr.c ~ 659 (vr_attach) mtx_init(&sc->vr_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, MTX_DEF | MTX_RECURSE); VR_LOCK(sc); << >> /usr/src/sys/pci/if_vrreg.h ~ 468 #define VR_LOCK(_sc) mtx_lock(&(_sc)->vr_mtx) << >> /usr/src/sys/vm/uma_core.c ~ 1332 (uma_zalloc_arg) if (!(flags & M_NOWAIT)) { KASSERT(curthread->td_intr_nesting_level == 0, ("malloc(M_WAITOK) in interrupt context")); WITNESS_SLEEP(1, NULL); } << >> /usr/src/sys/sys/lock.h ~ 233 #define WITNESS_SLEEP(check, lock) \ witness_sleep((check), (lock), __FILE__, __LINE__) << The solution, if I understand correctly is to drop the lock before entering the UMA code. The call of contigmalloc() in the vr driver is, I guess the route into the UMA code (via the vm ?), so would dropping the lock around the call to contigmalloc() be a solution, or am I missing the big picture? RFC? -- Dominic Marks Computer & Politics Geek [work]::[npl.co.uk] << dominic.marks at npl.co.uk >> [educ]::[umist.ac.uk] << notyet-known at umist.ac.uk >> [home]::[btinternet] << dominic_marks at btinternet.com >> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message