LOR route vr0

[Robert Watson]

On Sat, 27 Aug 2005, M. Warner Losh wrote:

> : Note that sets of ordered entries are terminated with a double-null.  This
> : declares that locks of type "tcp" preceed "tcpinp" which preceed
> : "so_snd".
>
> So would I add "ed1" to the list or "network driver"?

'ed1' I think, but to be honest, I'm not sure how lock classes interact 
with WITNESS.  John should be able to tell us, but you can take a look at 
the WITNESS tables by breaking into DDB and running "show witness", and 
see what it identifies it as?

In some ways, "network driver" might actually be better as it would let us 
make universal assertions across drivers.

> : If I had to guess, you do a media status update, which can cause routing
> : socket events indicating the link went up or down.
>
> No link moditoring, since the ED card I'm testing has no mii bus. That 
> might be ANOTHER problem, but it isn't this one :-).

Okidoki.

> : I think this case should be OK, and we should document that as being the
> : case using a hard-coded witness entry.
>
> rearranging the code in this case would be at the very least awkward. 
> Maybe quite difficult, but likely doable.

I think we need to make the if_addr_mtx follow device driver mutexes in 
the lock order because device drivers have an explicit need to acquire it 
while frobbing state.  I'll peruse the if_addr_mtx consuming code in the 
network stack and see if we accidentally call into anything (specifically 
device drivers) while holding the mutex.  I meant not to, but I may have 
done.  I think I was fairly careful to avoid calling the routing code 
while holding it.

Robert N M Watson