Crossbow team, If you read the Public Comments in 6871916, there is an open question regarding why mac_set_mtu() calls mac_mark_exclusive(). I personally don't see why the i_mac_perim_enter() on its own doesn't implement the exclusivity semantics required by the function (it's essentially just a kernel wrapper around setting the "mtu" link property). Can anyone shed some light on this?
Aside from panicing the system due to 6871916, this also has the negative side-effect of preventing other threads from issuing mac_open() while mac_set_mtu() is in progress (other threads will get back EBUSY). It doesn't seem right to me that opening /dev/net/foo0 (for example) would return EBUSY while setting the "mtu" link property, but not any other link property, or issuing any other "administrative" operation that requires the perimeter (such as adding multicast addresses, etc.). -Seb
