Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Oct 2012 08:54:45 -0500
From:      Guy Helmer <guy.helmer@gmail.com>
To:        "Alexander V. Chernikov" <melifaro@freebsd.org>
Cc:        freebsd-net@freebsd.org, FreeBSD Stable <freebsd-stable@freebsd.org>
Subject:   Re: 8.3: kernel panic in bpf.c catchpacket()
Message-ID:  <1EDA1615-2CDE-405A-A725-AF7CC7D3E273@gmail.com>
In-Reply-To: <5075C05E.9070800@FreeBSD.org>
References:  <4B5399BF-4EE0-4182-8297-3BB97C4AA884@gmail.com> <59F9A36E-3DB2-4F6F-BB2A-A4C9DA76A70C@gmail.com> <5075C05E.9070800@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Oct 10, 2012, at 1:37 PM, Alexander V. Chernikov =
<melifaro@freebsd.org> wrote:

> On 10.10.2012 00:36, Guy Helmer wrote:
>>=20
>> On Oct 8, 2012, at 8:09 AM, Guy Helmer <guy.helmer@gmail.com> wrote:
>>=20
>>> I'm seeing a consistent new kernel panic in FreeBSD 8.3:
>>> I'm not seeing how bd_sbuf would be NULL here. Any ideas?
>>=20
>> Since I've not had any replies, I hope nobody minds if I reply with =
more information.
>>=20
>> This panic seems to be occasionally triggered now that my user land =
code is changing the packet filter a while after the bpd device has been =
opened and an initial packet filter was set (previously, my code did not =
change the filter after it was initially set).
>>=20
>> I'm focusing on bpf_setf() since that seems to be the place that =
could be tickling a problem, and I see that bpf_setf() calls reset_d(d) =
to clear the hold buffer. I have manually verified that the BPFD lock is =
held during the call to reset_d(), and the lock is held every other =
place that the buffers are manipulated, so I haven't been able to find =
any place that seems vulnerable to losing one of the bpf buffers. Still =
searching, but any help would be appreciated.
>=20
> Can you please check this code on -current?
> Locking has changed quite significantly some time ago, so there is =
good chance that you can get rid of this panic (or discover different =
one which is really "new") :).

I'm not ready to run this app on current, so I have merged revs 229898, =
233937, 233938, 233946, 235744, 235745, 235746, 235747, 236231, 236251, =
236261, 236262, 236559, and 236806 to my 8.3 checkout to get code that =
should be virtually identical to current without the timestamp changes.

Unfortunately, I have only been able to trigger the panic in my test lab =
once -- so I'm not sure whether a lack of problems with the updated code =
will be indicative of likely success in the field where this has been =
trigged regularly at some sites=85

Thanks,
Guy




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1EDA1615-2CDE-405A-A725-AF7CC7D3E273>