svn commit: r233937 - in head/sys: kern net security/mac
Alexander V. Chernikov
melifaro at ipfw.ru
Fri Apr 20 08:57:48 UTC 2012
On 17.04.2012 01:29, Adrian Chadd wrote:
> On 15 April 2012 23:33, Alexander V. Chernikov<melifaro at freebsd.org> wrote:
>> On 16.04.2012 01:17, Adrian Chadd wrote:
>>> This has broken (at least) net80211 and bpf, with LOR:
>> Yes, it is. Please try the attached patch
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
> 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.
More information about the svn-src-all