Re: LOR found in March 15th 6.0 Current

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Fri, 1 Apr 2005 15:46:24 +0000 (GMT)
On Fri, 1 Apr 2005, Jon Noack wrote:

> What's up with rtentry (rtentry) _at_ /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
Received on Fri Apr 01 2005 - 13:49:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:31 UTC