svn commit: r233937 - in head/sys: kern net security/mac

[Alexander V. Chernikov]

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:
>>>
>>> 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
>