Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Apr 2012 12:53:32 +0400
From:      "Alexander V. Chernikov" <melifaro@ipfw.ru>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        svn-src-head@freebsd.org, freebsd-net@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r233937 - in head/sys: kern net security/mac
Message-ID:  <4F91240C.3050703@ipfw.ru>
In-Reply-To: <CAJ-Vmo=dLhW8GjBMB-snHcCd1e3aaoqasBQkmqLRHwSQt5B5Xg@mail.gmail.com>
References:  <201204060653.q366rwLa096182@svn.freebsd.org> <4F7E9413.20602@FreeBSD.org> <CAJ-VmonJ%2BZXrwgrwc3eoDvf6oMmip9zf2TFLpvjqahHgdcZdxw@mail.gmail.com> <4F8BBD4E.1040106@FreeBSD.org> <CAJ-Vmo=dLhW8GjBMB-snHcCd1e3aaoqasBQkmqLRHwSQt5B5Xg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 17.04.2012 01:29, Adrian Chadd wrote:
> On 15 April 2012 23:33, Alexander V. Chernikov<melifaro@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
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F91240C.3050703>