From owner-freebsd-stable@FreeBSD.ORG Fri Oct 12 13:54:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F80DF99; Fri, 12 Oct 2012 13:54:52 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id C54F28FC0A; Fri, 12 Oct 2012 13:54:51 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so6289728iea.13 for ; Fri, 12 Oct 2012 06:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wHTztVl0ei7EuNbrI51YHC0fqd3WZSkJEpNNt/K0BW8=; b=I9IU8qdV3Ttia4+klb2bfMgGSZu9rhxFkwnx4uJbGNU/5k+eidDuR+iUJraOvCoKU7 K9SdYmvXYq0jzp3loHWdEfzaaJ28DMJThEQ85W6Cqv7O0tQAgPw747ZfsjUs4bxFc8T4 zQguxYQ/CkbegLUt3IYmK9UN0XPljPotAZv+uxpvNxpQHJ3QtSvxTrd+D3j+xiNkyO3c gn7Ut6o9C3A5nTaYxJFkfjaZc8bX07H4h7BweFCd1XJkcio2laT1GMZKUBKcM1Aj/EHi IuMc1WqlH9wbXpvly+67ZdQrVNtK1JLfN8psTvRRC9/2fZKysWvpRl8cuFI62Xj08zuS l+/g== Received: by 10.50.236.74 with SMTP id us10mr2366636igc.5.1350050090407; Fri, 12 Oct 2012 06:54:50 -0700 (PDT) Received: from [192.168.221.83] ([216.81.189.9]) by mx.google.com with ESMTPS id uq6sm1541017igb.14.2012.10.12.06.54.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 06:54:49 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 8.3: kernel panic in bpf.c catchpacket() From: Guy Helmer In-Reply-To: <5075C05E.9070800@FreeBSD.org> Date: Fri, 12 Oct 2012 08:54:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1EDA1615-2CDE-405A-A725-AF7CC7D3E273@gmail.com> References: <4B5399BF-4EE0-4182-8297-3BB97C4AA884@gmail.com> <59F9A36E-3DB2-4F6F-BB2A-A4C9DA76A70C@gmail.com> <5075C05E.9070800@FreeBSD.org> To: "Alexander V. Chernikov" X-Mailer: Apple Mail (2.1499) Cc: freebsd-net@freebsd.org, FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 13:54:52 -0000 On Oct 10, 2012, at 1:37 PM, Alexander V. Chernikov = wrote: > On 10.10.2012 00:36, Guy Helmer wrote: >>=20 >> On Oct 8, 2012, at 8:09 AM, Guy Helmer 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