On 27-Jul-01 Bill Fenner wrote:
> 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).
This is a problem that needs to be solved, since you a lock order
reversal means that you can get in a deadlock, which is a Bad
Thing (tm). However, the networking stack is being redone, which
will involve redoing the network driver locks, so basically the
network driver locks are on hold until the stack itself is done.
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message