Date: Wed, 29 May 2019 03:23:23 +0300 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: Gleb Smirnoff <glebius@freebsd.org>, "Andrey V. Elsukov" <ae@freebsd.org>, kib@freebsd.org Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r348303 - head/sys/net Message-ID: <a7694fb5-2353-fcc1-5bfe-04064fc5825c@yandex.ru> In-Reply-To: <20190529001046.GC21836@FreeBSD.org> References: <201905271241.x4RCffTm047128@repo.freebsd.org> <20190529001046.GC21836@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
29.05.2019 3:10, Gleb Smirnoff пишет:
> Hi Andrey,
>
> I made a different change to mitigate this panic: don't clear the pointer.
>
> --- a/FreeBSD/sys/net/bpf.c
> +++ b/FreeBSD/sys/net/bpf.c
> @@ -857,7 +857,6 @@ bpf_detachd_locked(struct bpf_d *d, bool detached_ifp)
> /* Save bd_writer value */
> error = d->bd_writer;
> ifp = bp->bif_ifp;
> - d->bd_bif = NULL;
> if (detached_ifp) {
> /*
> * Notify descriptor as it's detached, so that any
>
> Since every bpf_d holds a reference on bpf_if until delayed free happens,
> the the bpf_if is going to be valid.
>
> This allows not to use epoch_wait and run fully async. The patch above is
> a minimal patch: with NULL assignment removed, several more pieces of code
> can be removed in bpf.c
>
> Of course your patch also is going to work, but what do you think:
> are there any landmines with fully async approach?
Hi,
bpf_mtap() is not the only consumer of bd_bif, some of them expect it
becomes NULL when descriptor is detached.
--
WBR, Andrey V. Elsukov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a7694fb5-2353-fcc1-5bfe-04064fc5825c>