From owner-freebsd-questions@FreeBSD.ORG Wed Nov 26 09:27:53 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 999B3DCC for ; Wed, 26 Nov 2014 09:27:53 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 201E4B18 for ; Wed, 26 Nov 2014 09:27:52 +0000 (UTC) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.9/8.14.9) with ESMTP id sAQ9Rcfn039011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 26 Nov 2014 09:27:44 GMT (envelope-from matthew@freebsd.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=freebsd.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk sAQ9Rcfn039011 Authentication-Results: smtp.infracaninophile.co.uk/sAQ9Rcfn039011; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <54759D00.70201@freebsd.org> Date: Wed, 26 Nov 2014 09:27:28 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: Relayd crashing Kernel on 10.1 References: <894145A3DDBDEF4880E00D334DCD872618A8B2DE@MXS2.zuv.uni-muenchen.de> In-Reply-To: <894145A3DDBDEF4880E00D334DCD872618A8B2DE@MXS2.zuv.uni-muenchen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ssf2e5R5Mb16q88R89W4rpQdBJnRXKmcf" X-Virus-Scanned: clamav-milter 0.98.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 09:27:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ssf2e5R5Mb16q88R89W4rpQdBJnRXKmcf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/26/14 08:43, Kolontai Andrej wrote: > Hello @all, >=20 > I'm new to this list and hope this is the right place to ask.=20 > We are using FreeBSD for our Firewalls and are actually happy with it. = Since recently we use relayd (installed via pkg) to do some load balancin= g stuff. On a freshly installed machine running 10.0-RELEASE everything w= orked fine.=20 > On monday, I tried to upgrade to 10.1-RELEASE using freebsd-update as d= escribed in the handbook chapter 24. At first everything looked good but = relayd wouldn't come up: >=20 > "Nov 24 10:50:48 flutters relayd[3300]: fatal: cannot add rule: Operati= on not supported by device > Nov 24 10:50:48 flutters relayd[3293]: lost child: pfe exited abnormall= y" >=20 > When I tried to start it with /usr/local/etc/rc.d/relayd start the kern= el panicked. I had to roll back the update (which worked fine). However, = I was able to reproduce this behavior on a virtual machine.=20 >=20 >=20 > My guess is it happens here: > #7 0xffffffff81a37954 in pfr_detach_table (kt=3D0x0) > at /usr/src_10.1.0/sys/modules/pf/../../netpfil/pf/pf_table.c:2047 >=20 > The corresponding code is: > void > pfr_detach_table(struct pfr_ktable *kt) > { >=20 > PF_RULES_WASSERT(); > KASSERT(kt->pfrkt_refcnt[PFR_REFCNT_RULE] > 0, ("%s: refcount %= d\n", > __func__, kt->pfrkt_refcnt[PFR_REFCNT_RULE])); >=20 > if (!--kt->pfrkt_refcnt[PFR_REFCNT_RULE]) > pfr_setflags_ktable(kt, kt->pfrkt_flags&~PFR_TFLAG_REFE= RENCED); > } >=20 > From what I know about C programming: kt is not supposed to be 0x0.=20 > My guess was that some data structure has changed between 10.0 and 10.1= kernels. So a recompile of relayd should fix that. It did. I compiled it= from the ports and it worked.=20 >=20 > Now my question ist: did I do something wrong? Maybe compiling is the = preferred method over using binaries? I'm still trying to figure out what= the "stay-out-of-trouble"-mode on FreeBSD is (like yum -y update). But = I'd rather use the binaries.=20 >=20 >=20 > Viele Gr=C3=BC=C3=9Fe=20 >=20 Hi, Kolontai, What you have discovered here is clearly a bug. It seems that relayd is poking around in kernel internals in a way that makes it particularly fragile when the kernel is updated. That, or else somebody slipped up and 10.1-RELEASE has not preserved KBI compatibility with 10.0-RELEASE. Either way, it's a bug that needs to be addressed. Could you report this via Bugzilla please? https://bugs.freebsd.org/bugzilla/enter_bug.cgi I'd start by classifying this as a kernel bug, since userland processes really aren't meant to be able to cause panics. This does mean that relayd from the FreeBSD pkg repositories is essentially only usable on 10.0 until the end of January when 10.0 goes out of support -- the package builder uses the earliest supported version from each major branch for building, as there is meant to be forwards ABI and KBI compatibility within each major branch. There are a few other programs like that, all of which tend to have a far too intimate knowledge of various kernel internals. lsof is a case in point. As you say, a work-around is to build the package locally. Cheers, Matthew --Ssf2e5R5Mb16q88R89W4rpQdBJnRXKmcf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUdZ0KXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEABRPxDgqeTnW5oP/3j9teZACzErJ7VMZCPJ4Z7I XNdY7j8SStIOWLVydDghIZZSNL0XpZBBxn79Zx1XJatyV4Qp5ZRsW4FMnQaZz5YI 0X7aV40myIJgCo9xR/k5KU0VnyGsgVooUUe4hudvZ4EqC57fzf/kQXi7AkUPqKeY lfa7uM+ZxRD/p35QPfs+sLF8dmMS4Yc/mKQt7I3nxsgCWeUj8DIZj594gOPThMLH z6nFDIziaCua8rnw0y+fPpuQmGsO66A9IQzi1Ov6SGBqtHfk4k33IV5vpbBCulIp uZRqOfpK3pC1yMJarUy5msQHE6x8BpBmrk7XYHp5i8qrY4cXYd47mSA6SnrpqZan oZ+VBlmze12JzV1N2L2FZOpRi8mrZg4OpbVz0ctq3fecbLPSXiA+tqACFbZcU7wK 9ZY5PWgE6w8EhHsMZm3DQ6kaKleLgcx0p6ulorere3eIRX9XaQuKW7CZX7BrYtu7 tw462e19ep4wkArM+7FFa8ipSE/zrFPZ54aqPlqZzlZvUNt2DPMoFp2njIQHY+5Q 8zAfC4v/beL/Qp50fdEFmSx6XH0hkjL80CdyMVXZDAK33ENltFwa/Suar13kkCTg //u8I66Yd+wRHV+WV0Bkj1hJ6o7BvbS0BrQ5NTy3y7BqOEgVJl3jorhKSb+Uo3no aQkeuOQ5meHCNicUVIa/ =Wg3Z -----END PGP SIGNATURE----- --Ssf2e5R5Mb16q88R89W4rpQdBJnRXKmcf--