Date: Tue, 27 Feb 2018 10:25:24 +0545 From: "Kristof Provost" <kristof@sigsegv.be> To: "Joe Jones" <joe@stream-technologies.com> Cc: freebsd-pf@freebsd.org Subject: Re: Kernel Panic Message-ID: <9F39A687-FB34-4984-B969-5264DF38544E@sigsegv.be> In-Reply-To: <5A93EDC9.7020407@stream-technologies.com> References: <5A842FC6.7020806@stream-technologies.com> <FCB6BE6F-5346-42EC-ACB2-9CD99A1A16F0@sigsegv.be> <5A8443BF.8040208@stream-technologies.com> <5289570D-24E1-4292-B4D2-D2F67D7D2D4F@sigsegv.be> <5A93EDC9.7020407@stream-technologies.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 Feb 2018, at 17:06, Joe Jones wrote:
> Hi Kristof,
>
> we are not updating rules during the test although in production we
> will reload the rule set from time to time. We are constantly adding
> and removing from tables though, using the DIOCRADDADDRS and
> DIOCRDELADDRS ioctl, also DIOCKILLSTATES is being called a lot. These
> are all in response to RADIUS events. We tried using pfctl shell
> command rather than calling ioctl directly, to check that it wasn't a
> problem with how we are calling the ioctl.
>
That’s interesting.
The panic leads me to suspect something’s wrong with the
kt->pfrkt_ipv4->rt, which would explain why we get the unexpected NULL
result.
My first guess at the cause would be a race condition, where it’s
being modified (through one of the ioctls you do) while the
pfr_pool_get() is walking it.
I don’t immediately see where that’d happen though, because both
DIOCRADDADDRS and DIOCRDELADDRS take the rules lock (and pfr_pool_get()
takes it too).
It might be interesting to run this with these extra asserts (and be
sure to enable INVARIANTS).
diff --git a/sys/netpfil/pf/pf_table.c b/sys/netpfil/pf/pf_table.c
index 18342a94073..cad9b4ea89f 100644
--- a/sys/netpfil/pf/pf_table.c
+++ b/sys/netpfil/pf/pf_table.c
@@ -962,6 +962,8 @@ pfr_unroute_kentry(struct pfr_ktable *kt, struct
pfr_kentry *ke)
struct radix_node *rn;
struct radix_head *head = NULL;
+ PF_RULES_WASSERT();
+
if (ke->pfrke_af == AF_INET)
head = &kt->pfrkt_ip4->rh;
else if (ke->pfrke_af == AF_INET6)
@@ -1855,6 +1859,8 @@ pfr_destroy_ktable(struct pfr_ktable *kt, int
flushaddr)
{
struct pfr_kentryworkq addrq;
+ PF_RULES_WASSERT();
+
if (flushaddr) {
pfr_enqueue_addrs(kt, &addrq, NULL, 0);
pfr_clean_node_mask(kt, &addrq);
Regards,
Kristof
From owner-freebsd-pf@freebsd.org Tue Feb 27 14:56:00 2018
Return-Path: <owner-freebsd-pf@freebsd.org>
Delivered-To: freebsd-pf@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBBEEF2CAF2
for <freebsd-pf@mailman.ysv.freebsd.org>; Tue, 27 Feb 2018 14:55:59 +0000 (UTC)
(envelope-from Joe@stream-technologies.com)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com
(mail-ve1eur01on0624.outbound.protection.outlook.com
[IPv6:2a01:111:f400:fe1f::624])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
(Client CN "mail.protection.outlook.com",
Issuer "Microsoft IT TLS CA 4" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 06D977BAE1
for <freebsd-pf@freebsd.org>; Tue, 27 Feb 2018 14:55:58 +0000 (UTC)
(envelope-from Joe@stream-technologies.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=streamtechnologiesuk.onmicrosoft.com;
s=selector1-streamtechnologies-com01e;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
bh=byxZdw9UV3jYemz9nqard5RMk7goQjOKwdYgnyy1QNg=;
b=qcjGbiChUBe/qqLnynkK2HMeGtrjWUdc06w4KZhRwTQ90YArw6g65mG6CuA+pTT0kV2YyohK+SoiesuCVDXIZ8CImjvhT9OuenjeX07vkL3pVhz25vMvlzJGAiF/Jtkj/vRuXTHop4HgvdsSYwLTPrO7IzKo7mtTRAige9eduxE=
Received: from [192.168.6.128] (212.250.79.109) by
VI1PR07MB3421.eurprd07.prod.outlook.com (2603:10a6:802:23::31) with Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.548.6; Tue, 27 Feb 2018 14:55:55 +0000
Subject: Re: Kernel Panic
To: Kristof Provost <kristof@sigsegv.be>
Cc: freebsd-pf@freebsd.org
References: <5A842FC6.7020806@stream-technologies.com>
<FCB6BE6F-5346-42EC-ACB2-9CD99A1A16F0@sigsegv.be>
<5A8443BF.8040208@stream-technologies.com>
<5289570D-24E1-4292-B4D2-D2F67D7D2D4F@sigsegv.be>
<5A93EDC9.7020407@stream-technologies.com>
<9F39A687-FB34-4984-B969-5264DF38544E@sigsegv.be>
From: Joe Jones <joe@stream-technologies.com>
Message-ID: <19aedb50-34c0-417d-fc1e-e8d519655684@stream-technologies.com>
Date: Tue, 27 Feb 2018 14:55:53 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <9F39A687-FB34-4984-B969-5264DF38544E@sigsegv.be>
Content-Language: en-US
X-Originating-IP: [212.250.79.109]
X-ClientProxiedBy: PR0P264CA0018.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100::30)
To VI1PR07MB3421.eurprd07.prod.outlook.com
(2603:10a6:802:23::31)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e6e0b34d-6fe2-4fea-ff42-08d57df23479
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0;
RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020);
SRVR:VI1PR07MB3421;
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3421;
3:S0WhDpY/utmYqG9l1KmfZYrSvBTodpe5zYGzr66kITyL99fQEQxdCIwgVuk+U1E81OvcBFDc6IbRThI/FvJVJcWRsYjMD70yn+WlVoo0uba9Q5WBxlyRYT+2RhGme9DrzUoNfyvTXvualFWCCNtPJ1Zwd/xDealMUw0ajyTWvvpnGbTBmIGJGyYZIzKgDzeBynTHEATFJl+1JidMr+aJ8NSkSrGPPdR8r/KjQDIumN4ODtb4J4HN9tJ4qPDK4H/1;
25:AzeMZoeS9MaXsN8hueElOtgdClYNdu/B2uYA5efdSnu/m9o/Ldz2UpM7kCZVU6HdYFsmRG4crf0OI0Rhe8dTbK9yUvnX50xOEMD2q5QpKtlUfrDfDtCcKX4VFvkOPMFhba1aYeXoXh3NfABI0534eFXva/WSA2e7WOs9/L39u/SeSu+pa226iTPOnOrkzt5PYKihNkudv4BKiy2QUJw0ul5xu0qvnFLDtgN6/uI3JBubc/3kaCuDcvOsH2qJBhzx+GIPRckJLj/bLt0YXtJj14CuWAbBHOH/ECrcu5pLuBvhfEMd6uRS4tQUpTrthn3oMox5fSloUUaBfgLMQ7l/cQ==;
31:w0ARvgtOSjtBn7kWgWkqBxml1BzH2S9YNSfkV2xfLeKpNNS1YvGdluBzgrasxWHr8lqfRtR+SymMzPb6CFykXBuc2R3tXKQVrfm8XPbE2DXlzDEr/mEJdlmS+ohOfaq+bDSZK6Bx0KfO2kklYKaSzMIFa1AXEPqTVsSFSn5IrC3nJi+2Ym8USnQ+a0MFwFmYQzoHWmeFMMmbBAm9FTEopNXJVHM+TK31Y2faKpnxvII=
X-MS-TrafficTypeDiagnostic: VI1PR07MB3421:
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3421;
20:rKVvEau6J5JCW+5I3obxOrTqEBqMMNASLEkYAHgdlVfJhWdvNduSvUZcLCNPaPIqMx592MthN+xubbYvtXVrqyyrVYPUfPTZfYW9ulZ8AJbVCdqThANk3n/Q0Fh4saihBYKlxtiSDWOiUenUbt2NXMWXEUrEsUtoSXTks7ochok=;
4:Ckl8RISHY9ZHtiB8odks2bdLbwQDMbVPobkuWbE7vXEBqsNgSMusj1t0JW9va7doe9mS0D1miDRC4PfriLMsAVVCJp5EZWPbgv4/pmjcOQEXO2dkmDyhoOBkGLH00cV8MTbrIsWT5vK/wWJ3qYNk+xZThWuQRFs0b8k5MVCUHiz9sUeBHzPLKAxphGMvwyXxVeOVm0VMNifX/CyhbHAaCT0Tlv3D4JUpWq87uHm5OUleeSM7Q4qM4jur/v3U+pRccSd3/U4FbP72ijx6ZvE4gw==
X-Microsoft-Antispam-PRVS: <VI1PR07MB34214877B5349B35002E5EA6E4C00@VI1PR07MB3421.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0;
RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231220)(944501198)(93006095)(93001095)(3002001)(6041288)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011);
SRVR:VI1PR07MB3421; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3421;
X-Forefront-PRVS: 05961EBAFC
X-Forefront-Antispam-Report: SFV:NSPM;
SFS:(10009020)(6049001)(366004)(346002)(39850400004)(396003)(376002)(39380400002)(199004)(189003)(4326008)(117156002)(54896002)(65826007)(66066001)(386003)(86362001)(229853002)(93886005)(25786009)(6916009)(2950100002)(7736002)(52116002)(76176011)(6346003)(59450400001)(53546011)(77096007)(7116003)(80792005)(5660300001)(106356001)(33964004)(84326002)(186003)(16526019)(97736004)(105586002)(81166006)(316002)(31696002)(68736007)(81156014)(8676002)(58126008)(6116002)(31686004)(6246003)(2906002)(8936002)(65806001)(16576012)(3480700004)(16586007)(37036004)(64126003)(478600001)(65956001)(3846002)(221733001)(53936002)(36756003)(72206003)(6486002)(26005);
DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3421; H:[192.168.6.128]; FPR:;
SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: stream-technologies.com does not
designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is )
smtp.mailfrom=Joe@stream-technologies.com;
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR07MB3421;
23:BP/5ZLa9shPqYm67VLjtdE7rP9HhDQwa2sOoen/vm?=
=?us-ascii?Q?XeY0wbkaH0gwwVVigaxMt/nnle+vJd2cPnwOUO3/XVOw2J/bhncYoyD+ElOQ?=
=?us-ascii?Q?gIJYYqbbpjVKRydY7Hz5UbHIEDBX043jSF5b5O2PzW6DZOc/tFp2LBx09xIX?=
=?us-ascii?Q?cadxJAF0/rprlEhWAmE2K85CvUo0a9r7YMyrnNJ3BnCHfuDKlTxaAJMkmFPy?=
=?us-ascii?Q?jVlKIwTAdiIfDWQzg6kRvOjogiaC488pw51gmr0ejmWK/6qV6+YerVWKbqPZ?=
=?us-ascii?Q?l9QgGb4Xlh0ok4tEc9m8gZ9ijQqlhrpJK02Y9ecMclWMEByQuSRCRdApsL1F?=
=?us-ascii?Q?VcQTZAUXBRj/wxgT0vLmO7uZ9qHWozQOKA0mB58LStf/HxK6vpO01wlmkZaw?=
=?us-ascii?Q?B8h4ZPWygqw8iDnX1FDuMOO1SlxOEO+BdxLTECBC4tFe+BNJ4o+DEqwQocSo?=
=?us-ascii?Q?tHFNF4eBSPRmulzmmpNk6kaLC7j0bvyfT/AR6Xt/aqVIUCmGOm+uzApmSua8?=
=?us-ascii?Q?/EE3xu5nj6zwA17oRGVVYqXGOVebRGyRuLsaqNOSx82ssGGLP8AxfX7A3QO1?=
=?us-ascii?Q?llwW2BIOrbjy35mkziRI+TDk6ThMyvU+kK/rvKQ+5rPSDqXP5kMS/DDK4XeB?=
=?us-ascii?Q?UdW5cyc88xIHyl8FkNhEHoq5zN4s7Izo/GhZe7UZpIriOUL6J545Nbt7QLYL?=
=?us-ascii?Q?zk86gt2WOv7RQdbwDFSKYRzZojx/Nm662YCHi2pPMX32NkoADtLJDXCXlcdR?=
=?us-ascii?Q?Xh7KzRvKFH/bDrAL7Ex/JvrgPYqprOSBycjb37wNvpmqY6L4R6agX7MZ8w/M?=
=?us-ascii?Q?eAP0mBGV6l0Z1ux7LIvUTcf1ur2IiwrPkAhYTvtyApuybUkoq3TbtXQRCYhV?=
=?us-ascii?Q?OHEzsIT+iOiWXs2jEeE0y03inYIqXRb0XTf0hPXyRkpG/z1IP6wR8HzsZxa6?=
=?us-ascii?Q?Tw0Ct0tC8CgxJX2Di07evQhiScgd5b0AG5L/15z+uTeTF7wvXLLJQy0YROQ5?=
=?us-ascii?Q?LNa6krCM4bYkjIFKdcMn3MVNnvzK4WePwDrriuu0zAWJBwAiFvcpsSbuYcrd?=
=?us-ascii?Q?Q7TdmGIChBtu7W1SDhlaUvgR7CIFiHrI2kYjlhAOiWho2edpl40xxb+qlm5n?=
=?us-ascii?Q?+XaMfuB9vFtPLYCdlcIIJAVOo5/fgm1TojJwxjbH3lX0mawmYL4UTRsNvrPs?=
=?us-ascii?Q?DPxs3cFInM8b9gSRzg7FlagvBcQLrS1stX7qW9tPKMoG2HFYHALhHWJdP8W1?=
=?us-ascii?Q?cK1O0QL37poBvzJTytzjIugzEzCYR+kBdRsSDVoNrAuTqYI0UI03dxPg5z4Z?=
=?us-ascii?Q?lvXcwPHLOq2YzAfEYIVRyagn8YCWZK5xRckJwWUwKsFzpgOcJpNpAaovc1Rg?=
=?us-ascii?Q?ejRwb9Mj0zF26cucWQC8DknpTByO8ZVPIocOrlSPFgM6Jk2t/Fjat+DKbbwm?=
=?us-ascii?Q?VmtS37vME7F3rulGlzpsUmW5z/g6wJmv2PNtYNpBI2y8cfgtMNU?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3421;
6:xschFrveGjNIBog4LV07JiJbTR/LgBZNNKrJANf8QA6LPIEyePgRBMoDu/0aenf0KzW3EqJayK3RvR4ohvNImHHYF6DEJEh9vd2mC/BBi/+Ie5mUrwpMeRKOulenFXh8lRv9UfVjjwqeEEvSf/P8sHEUKxNr7nwuISq+h+0VRfNnQRZscwrJD9VwT6/ORBxgxsRr7pOEk7FhVamqvap+rt5Lzo1bbC9pMx3YH24wkgOE+sp6mhFmAJBZk+k3eqQVzUb5pvPO29bLXN5OLcymcaGdUvMYZIcvRhRdfyIwegKHyyd8OqL5dhTl7+XfLuCVT/zW+F3fDre0Rg9WF5H+O8bVb/EAnm0AVzZkz8sGvTU=;
5:DcFWe0OzkVFvWBJpN92+qhr07A0ss4sW5Pjbh4BeATZE9oLdIPFkwCWoGEj0Fz11YlHV4RQ5kKHj50g18FKIcIgDd2gs+UbP4U2ewNIiBDXw6XdPHsJwEfWJTEko39e3qdIRehivdVn6LF08F8fPOuqF0XRj6651bzUfvFOrZMc=;
24:TBlEseYomqVi0K1kA5DjwkpdMkC0TBXgVN8X/ZHhXxDIjYvx64o1K6G/JuTYLFgExEcm5iQNEtqCFMMVLRQii/uc7P0bVeZDq/LQmt2kRjc=;
7:Uqw9Z9CUDIpNjhzyOevBPqi9sTiAaKNEYwWTfxcI6RN7/KQcxln5SbGXrR/eR+qQvSOtTjZojKTbOBd9Fbd0sRuXbo+rFr1sgkb9VIPci51pcqOHgHIrdd1nI71Kad+kexaG64QD5Gi48wEnGFKbNYx/bPnwZj2hxmYH2jpK/nnhHX0tBKcMTmH9FlU1d7yoPKpQs49uAv/p92LatF1FBF7BiRZnmJS/0EdozJdHTg+WZQyGBhmw6VpevQwZQRVn
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: stream-technologies.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2018 14:55:55.7198 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e6e0b34d-6fe2-4fea-ff42-08d57df23479
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 720fa073-5781-43bf-bc14-7bef2603ed21
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3421
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.25
X-BeenThere: freebsd-pf@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: "Technical discussion and general questions about packet filter
\(pf\)" <freebsd-pf.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-pf>,
<mailto:freebsd-pf-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-pf/>;
List-Post: <mailto:freebsd-pf@freebsd.org>
List-Help: <mailto:freebsd-pf-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-pf>,
<mailto:freebsd-pf-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Feb 2018 14:56:00 -0000
Hi,
we have a kernel panic after compiling with witness and invariant
Feb 27 13:49:33 sovapn1 kernel: lock order reversal:
Feb 27 13:49:33 sovapn1 kernel: 1st 0xfffffe000fed78b8 pf_idhash (pf_idhash) @ /usr/src/sys/netpfil/pf/pf.c:1078
Feb 27 13:49:33 sovapn1 kernel: 2nd 0xfffff8001e0474a8 pfsync (pfsync) @ /usr/src/sys/netpfil/pf/if_pfsync.c:1667
Feb 27 13:49:33 sovapn1 kernel: stack backtrace:
Feb 27 13:49:33 sovapn1 kernel: #0 0xffffffff80a9efe0 at witness_debugger+0x70
Feb 27 13:49:33 sovapn1 kernel: #1 0xffffffff80a9eed3 at witness_checkorder+0xe23
Feb 27 13:49:33 sovapn1 kernel: #2 0xffffffff80a20aad at __mtx_lock_flags+0x9d
Feb 27 13:49:33 sovapn1 kernel: #3 0xffffffff826d9f9d at pfsync_insert_state+0x7d
Feb 27 13:49:33 sovapn1 kernel: #4 0xffffffff826ea729 at pf_state_insert+0x8b9
Feb 27 13:49:33 sovapn1 kernel: #5 0xffffffff826f444c at pf_test_rule+0x2bbc
Feb 27 13:49:33 sovapn1 kernel: #6 0xffffffff826eec58 at pf_test+0x1598
Feb 27 13:49:33 sovapn1 kernel: #7 0xffffffff826ffb2d at pf_check_in+0x1d
Feb 27 13:49:33 sovapn1 kernel: #8 0xffffffff80b488c4 at pfil_run_hooks+0xa4
Feb 27 13:49:33 sovapn1 kernel: #9 0xffffffff80ba5757 at ip_tryforward+0x157
Feb 27 13:49:33 sovapn1 kernel: #10 0xffffffff80ba7a8a at ip_input+0x38a
Feb 27 13:49:33 sovapn1 kernel: #11 0xffffffff80b47a00 at netisr_dispatch_src+0x80
Feb 27 13:49:33 sovapn1 kernel: #12 0xffffffff80b309ce at ether_demux+0x15e
Feb 27 13:49:33 sovapn1 kernel: #13 0xffffffff80b317ee at ether_nh_input+0x31e
Feb 27 13:49:33 sovapn1 kernel: #14 0xffffffff80b47a00 at netisr_dispatch_src+0x80
Feb 27 13:49:33 sovapn1 kernel: #15 0xffffffff80b30d62 at ether_input+0x62
Feb 27 13:49:33 sovapn1 kernel: #16 0xffffffff82671427 at igb_rxeof+0x6e7
Feb 27 13:49:33 sovapn1 kernel: #17 0xffffffff826708fe at igb_msix_que+0xee
we compiled with
options INVARIANTS
options INVARIANT_SUPPORT
options WITNESSoptions WITNESS_SKIPSPIN
options WITNESS_KDB
we went back to the 11.1 release as the relenge branch didn't compile
for us (probably our fault).
Regards
Joe Jones
On 27/02/18 04:40, Kristof Provost wrote:
>
> On 26 Feb 2018, at 17:06, Joe Jones wrote:
>
> Hi Kristof,
>
> we are not updating rules during the test although in production
> we will reload the rule set from time to time. We are constantly
> adding and removing from tables though, using the DIOCRADDADDRS
> and DIOCRDELADDRS ioctl, also DIOCKILLSTATES is being called a
> lot. These are all in response to RADIUS events. We tried using
> pfctl shell command rather than calling ioctl directly, to check
> that it wasn't a problem with how we are calling the ioctl.
>
> That’s interesting.
>
> The panic leads me to suspect something’s wrong with the
> kt->pfrkt_ipv4->rt, which would explain why we get the unexpected NULL
> result.
> My first guess at the cause would be a race condition, where it’s
> being modified (through one of the ioctls you do) while the
> pfr_pool_get() is walking it.
>
> I don’t immediately see where that’d happen though, because both
> DIOCRADDADDRS and DIOCRDELADDRS take the rules lock (and
> pfr_pool_get() takes it too).
>
> It might be interesting to run this with these extra asserts (and be
> sure to enable INVARIANTS).
>
> |diff --git a/sys/netpfil/pf/pf_table.c b/sys/netpfil/pf/pf_table.c
> index 18342a94073..cad9b4ea89f 100644 --- a/sys/netpfil/pf/pf_table.c
> +++ b/sys/netpfil/pf/pf_table.c @@ -962,6 +962,8 @@
> pfr_unroute_kentry(struct pfr_ktable *kt, struct pfr_kentry *ke)
> struct radix_node *rn; struct radix_head *head = NULL; +
> PF_RULES_WASSERT(); + if (ke->pfrke_af == AF_INET) head =
> &kt->pfrkt_ip4->rh; else if (ke->pfrke_af == AF_INET6) @@ -1855,6
> +1859,8 @@ pfr_destroy_ktable(struct pfr_ktable *kt, int flushaddr) {
> struct pfr_kentryworkq addrq; + PF_RULES_WASSERT(); + if (flushaddr) {
> pfr_enqueue_addrs(kt, &addrq, NULL, 0); pfr_clean_node_mask(kt, &addrq); |
>
> Regards,
> Kristof
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9F39A687-FB34-4984-B969-5264DF38544E>