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>