On 17.04.2012 01:29, Adrian Chadd wrote:
On 15 April 2012 23:33, Alexander V. Chernikov<melif...@freebsd.org> wrote:
On 16.04.2012 01:17, Adrian Chadd wrote:
Hi,
This has broken (at least) net80211 and bpf, with LOR:
Yes, it is. Please try the attached patch
Hi,
Hello!
Sorry for the late reply, answering for both letters.
This seems like a very, very complicated diff.
* You've removed BPF_LOCK_ASSERT() inside bpf_detachd_locked() - why'd
you do that?
* You removed a comment ("We're already protected by the global lock")
which is still relevant/valid
Both should be added back, thanks.
* There are lots of modifications to the read/write locks here - I'm
not sure whether they're at all relevant to my immediate problem and
may belong in separate commits
Most of the patch is not directly relevant to the problem. It solves
several new problems and a bunch of very old bugs due to lack of locking.
Is there a document somewhere which describes what the "new" style BPF
locking should be?
Are there any other places (except src) where such documentation should
reside?
I "just" added BPF_LOCK() / BPF_UNLOCK() around all the calls to
bpf_detachd() which weren't locked (there were a few.)
Unfortunately, this is not enough. There is possibility that bpf_setif()
is called immediately before rw_destroy() in bpfdetach().
For example, you can easily trigger panic on any 8/9/current SMP system
with 'while true; do ifconfig vlan222 create vlan 222 vlandev em0 up ;
tcpdump -pi vlan222 & ; ifconfig vlan222 destroy ; done'
There is also possible use-after-free for bpfif structure (since we're
freeing it _before_ interface routes are cleaned up). This is why
delayed free is needed.
One final question - should the BPF global lock be recursive?
It seems it really should be recursive now.
thanks,
Adrian
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
