Re: Lock order reversals that aren't problematic
On Mon, Jul 30, 2001 at 12:31:43PM -0400, Garrett Wollman wrote: On Mon, 30 Jul 2001 09:28:03 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: However, the networking stack is being redone, By whom? I haven't seen anything about this posted to -net. I don't think John actually means redone, just locked down, or mutexified. -GAWollman -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Lock order reversals that aren't problematic
...since a lock order reversal means that you can get in a deadlock... Argh, of course. It's only not problematic if it's a uniprocessor and it doesn't take an interrupt at the wrong time. Sorry for being dense, I'm still used to spl() =) Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Lock order reversals that aren't problematic
On 30-Jul-01 Garrett Wollman wrote: On Mon, 30 Jul 2001 09:28:03 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: However, the networking stack is being redone, By whom? I haven't seen anything about this posted to -net. Err, bogon, networking stack _locking_ is being redone. (Missing keyword there) jlemon is heading up that task atm, but I don't know how far he has got. -GAWollman -- 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
RE: Lock order reversals that aren't problematic
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
RE: Lock order reversals that aren't problematic
On Mon, 30 Jul 2001 09:28:03 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: However, the networking stack is being redone, By whom? I haven't seen anything about this posted to -net. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Lock order reversals that aren't problematic
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). Thanks, Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
