svn commit: r347526 - head/sys/net

[Mark Johnston]

On Mon, May 13, 2019 at 06:09:59PM -0400, Li-Wen Hsu wrote:
> On Mon, May 13, 2019 at 3:38 PM Mark Johnston <markj at 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

The problem should be fixed by r347549.