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>