Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 May 2019 18:09:59 -0400
From:      Li-Wen Hsu <lwhsu@freebsd.org>
To:        Mark Johnston <markj@freebsd.org>
Cc:        "Andrey V. Elsukov" <ae@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org,  svn-src-head@freebsd.org, melifaro@freebsd.org
Subject:   Re: svn commit: r347526 - head/sys/net
Message-ID:  <CAKBkRUxDftmT-35P4uPxpF7QtDkLjMGyJewGR-pcV%2BfjdzJByw@mail.gmail.com>
In-Reply-To: <20190513193754.GA37655@raichu>
References:  <201905131345.x4DDjTRn092669@repo.freebsd.org> <20190513193754.GA37655@raichu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 13, 2019 at 3:38 PM Mark Johnston <markj@freebsd.org> wrote:
>
> On Mon, May 13, 2019 at 01:45:29PM +0000, Andrey V. Elsukov wrote:
> > Author: ae
> > Date: Mon May 13 13:45:28 2019
> > New Revision: 347526
> > URL: https://svnweb.freebsd.org/changeset/base/347526
> >
> > Log:
> >   Rework locking in BPF code to remove rwlock from fast path.
> >
> >   On high packets rate the contention on rwlock in bpf_*tap*() functions
> >   can lead to packets dropping. To avoid this, migrate this code to use
> >   epoch(9) KPI and ConcurrencyKit's lists.
> >
> >   * all lists changed to use CK_LIST;
> >   * reference counting added to bpf_if and bpf_d;
> >   * now bpf_if references ifnet and releases this reference on destroy;
> >   * each bpf_d descriptor references bpf_if when it is attached;
> >   * new struct bpf_program_buffer introduced to keep BPF filter programs;
> >   * bpf_program_buffer, bpf_d and bpf_if structures are freed by
> >     epoch_call();
> >   * bpf_freelist and ifnet_departure event are no longer needed, thus
> >     both are removed;
> >
> >   Reviewed by:        melifaro
> >   Sponsored by:       Yandex LLC
> >   Differential Revision:      https://reviews.freebsd.org/D20224
>
> This seems to introduce a possible recursion on the bpf cdev mutex.  Now
> bpfwrite() holds the mutex over the if_output call, which may enter
> bpf_mtap() via bridge_transmit(), and bpf_mtap() may attempt to
> reacquire the mutex.

It does, the sys.netinet.fibs_test.arpresolve_checks_interface_fib
case can trigger a panic:

root@:/usr/tests/sys/netinet # kyua test
fibs_test:arpresolve_checks_interface_fib
fibs_test:arpresolve_checks_interface_fib -> panic: _mtx_lock_sleep:
recursed on non-recursive mutex bpf @ /usr/src/sys/net/bpf.c:2325



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKBkRUxDftmT-35P4uPxpF7QtDkLjMGyJewGR-pcV%2BfjdzJByw>