Date: Fri, 1 Apr 2005 15:46:24 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Jon Noack <noackjr@alumni.rice.edu> Cc: Muthu_T@Dell.com Subject: Re: LOR found in March 15th 6.0 Current Message-ID: <Pine.NEB.3.96L.1050401154400.54012A-100000@fledge.watson.org> In-Reply-To: <424D6C80.4010304@alumni.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050401154400.54012A-100000>