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: >> >> On Oct 8, 2012, at 8:09 AM, Guy Helmer <guy.helmer@gmail.com> wrote: >> >>> 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? >> >> Since I've not had any replies, I hope nobody minds if I reply with more information. >> >> 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). >> >> 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. > > 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… Thanks, Guy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1EDA1615-2CDE-405A-A725-AF7CC7D3E273>