I'm curious what the long-term plan is for witness(4).  For
example, it complains about BPF and device locks being reversed
when BPF takes the device out of promiscuous mode --

lock order reversal
 1st 0xc04c1560 bpf global lock @ /usr/src/sys/net/bpf.c:365
 2nd 0xc1302b88 dc1 @ /usr/src/sys/pci/if_dc.c:3251

This is because when traffic is being handed to bpf from the
device, the device is locked so witness first sees dc1's
lock and then bpf's.  The lock reversal occurs when the socket
is closed; bpfclose() calls bpf_detachd() which calls ifpromisc()
which calls into the device, which obtains its lock, but bpf
is already locked..

It's hard to add this case to the blessed_list, since it
can be any ethernet driver paired with bpf.

Basically, I'm curious if this is a problem that needs to
be solved (i.e. the eventual goal is for witness to never
print any notices) or if this is expected behavior (i.e.
witness is expected to say things and it's up to the developer
to determine if a given thing that witness says is a problem).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to