From owner-freebsd-current@FreeBSD.ORG Fri Apr 1 15:49:45 2005 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 BB54E16A4CF for ; Fri, 1 Apr 2005 15:49:45 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8036943D1D for ; Fri, 1 Apr 2005 15:49:45 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id B1C5046B35; Fri, 1 Apr 2005 10:49:44 -0500 (EST) Date: Fri, 1 Apr 2005 15:46:24 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jon Noack In-Reply-To: <424D6C80.4010304@alumni.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Muthu_T@Dell.com Subject: Re: LOR found in March 15th 6.0 Current 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: Fri, 01 Apr 2005 15:49:45 -0000 On Fri, 1 Apr 2005, Jon Noack wrote: > What's up with rtentry (rtentry) @ /usr/src/sys/netinet/if_ether.c:445? > Here's a sampling of LORs seen with this line (all listed with status > "unknown"): > http://sources.zabbadoz.net/freebsd/lor.html#061 > http://sources.zabbadoz.net/freebsd/lor.html#062 > http://sources.zabbadoz.net/freebsd/lor.html#064 > http://sources.zabbadoz.net/freebsd/lor.html#068 > http://sources.zabbadoz.net/freebsd/lor.html#071 > http://sources.zabbadoz.net/freebsd/lor.html#074 > http://sources.zabbadoz.net/freebsd/lor.html#077 > > Are these false positives? There must have been some recent change, perhaps relating to link state notification, that caused a variety of network device drivers to call into the routing code while holding network interface mutexes. In general, the defined lock order is network stack locks before device driver locks, but in practice there are few situations where routing locks are held when calling into device drivers, or vice versa. While I've not looked closely at the route locking, it's reasonable to assume it would follow the same general trend in lock order -- that is, a routing lock should not be acquired while holding device driver locks. What someone could try doing to track down the specific code path is hard-code the relationship between the routing rtentry mutex and the device driver mutex in subr_witness.c, which will cause witness to fire for the earlier ordering event, rather than the conflicting ordering event (the above). Robert N M Watson