From owner-freebsd-pf@FreeBSD.ORG Mon Jun 3 11:06:50 2013 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 20BBD5DC for ; Mon, 3 Jun 2013 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 122ED13BC for ; Mon, 3 Jun 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r53B6ng9015118 for ; Mon, 3 Jun 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r53B6nBB015116 for freebsd-pf@FreeBSD.org; Mon, 3 Jun 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Jun 2013 11:06:49 GMT Message-Id: <201306031106.r53B6nBB015116@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/177810 pf [pf] traffic dropped by accepting rules is not counted o kern/177808 pf [pf] [patch] route-to rule forwarding traffic inspite o kern/176763 pf [pf] [patch] Removing pf Source entries locks kernel. o kern/176268 pf [pf] [patch] synproxy not working with route-to o kern/173659 pf [pf] PF fatal trap on 9.1 (taskq fatal trap on pf_test o bin/172888 pf [patch] authpf(8) feature enhancement o kern/172648 pf [pf] [ip6]: 'scrub reassemble tcp' breaks IPv6 packet o kern/171733 pf [pf] PF problem with modulate state in [regression] o kern/169630 pf [pf] [patch] pf fragment reassembly of padded (undersi o kern/168952 pf [pf] direction scrub rules don't work o kern/168190 pf [pf] panic when using pf and route-to (maybe: bad frag o kern/166336 pf [pf] kern.securelevel 3 +pf reload o kern/165315 pf [pf] States never cleared in PF with DEVICE_POLLING o kern/164402 pf [pf] pf crashes with a particular set of rules when fi o kern/164271 pf [pf] not working pf nat on FreeBSD 9.0 [regression] o kern/163208 pf [pf] PF state key linking mismatch o kern/160370 pf [pf] Incorrect pfctl check of pf.conf o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 52 problems total. From owner-freebsd-pf@FreeBSD.ORG Wed Jun 5 08:52:27 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2F7C3C15; Wed, 5 Jun 2013 08:52:27 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 3774D1C64; Wed, 5 Jun 2013 08:52:26 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id it19so693182bkc.13 for ; Wed, 05 Jun 2013 01:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=RhwcelCQpqAxDJ72aASwgKzRrHLb5Sq5Q1IaIK54REo=; b=muEOfzhTxJbfoJ3AGV4M0fafYBKSTDhyhUvVnL/Hn8wkkL2SpUTZRfBv3+5rvjjXSQ 4SLZK6QAUWZuXQMI+vU7nodCU+cQogf0NSwyIL/6tqth8acRNI0mklaoFE3n7O67CC/e j/E+qzH6ET/9GJbFrURL2dQJNWrn7kEFdXZPwQfQhzv/YBZRbGDp4iBiTrL+Nsyy5VNz 7bvj+Y3f91NJ5HZeO3u7AtOeG0Cpta9xW+SCLEVpACJC3ZA3kYsg7GmUgbz3EJgRV9N7 iIxd2iiFDBJloS7HtD46Cz4XUCbFvqFFmt+RbT16twSIUYZ2bFpkaMAC2ChAhHVEfd0p 0aSA== X-Received: by 10.204.62.137 with SMTP id x9mr9224354bkh.90.1370422344859; Wed, 05 Jun 2013 01:52:24 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id jm15sm25045160bkb.13.2013.06.05.01.52.22 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 05 Jun 2013 01:52:23 -0700 (PDT) Sender: Mikolaj Golub Date: Wed, 5 Jun 2013 11:52:20 +0300 From: Mikolaj Golub To: Nikos Vassiliadis Subject: Re: pf + vimage patch Message-ID: <20130605085219.GA53217@gmail.com> References: <51AC84EE.6020009@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51AC84EE.6020009@gmx.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 08:52:27 -0000 Hi, On Mon, Jun 03, 2013 at 01:58:38PM +0200, Nikos Vassiliadis wrote: > Hi, > > Please review this patch. It fixes some problems with pf and vimage. > For the time being only pf works. ALTQ, pflog, pfsync are not changed > nor tested but as time permits, I'll work on them. Basic packet > filtering functionality per VNET should be ok. > Thank you for working on this. I'd really like to see pf and vimage integrated, as it looks like one of the main stoppers to have vimage in GENERIC. I hoped more knowledgeable people would comment on this though. Anyway, not being familiar with pf, here is a couple of things I would recommend to make your patch more attractive for potential reviewers: 1) It looks like the patch can be split on several parts. A log message to every change describing why it is needed and what problem solves would be very helpful. As a tool to maintain such changes I personally prefer git. 2) You use spaces for indentation, where tabs should be. This adds unnecessary noise and makes the patch less readable. Also someone will need to fix this when eventually committing to the tree. 3) When generating diff from svn, adding -x-pu options will make the diff more readable. Also see some questions/comments below. > Index: sys/net/pfvar.h > =================================================================== > --- sys/net/pfvar.h (revision 251294) > +++ sys/net/pfvar.h (working copy) > @@ -901,7 +901,6 @@ > struct pf_ruleset *, struct pf_pdesc *, int); > extern pflog_packet_t *pflog_packet_ptr; > > -#define V_pf_end_threads VNET(pf_end_threads) > #endif /* _KERNEL */ > > #define PFSYNC_FLAG_SRCNODE 0x04 > Index: sys/netpfil/pf/pf.c > =================================================================== > --- sys/netpfil/pf/pf.c (revision 251294) > +++ sys/netpfil/pf/pf.c (working copy) > @@ -300,8 +300,6 @@ > > int in4_cksum(struct mbuf *m, u_int8_t nxt, int off, int len); > > -VNET_DECLARE(int, pf_end_threads); > - > VNET_DEFINE(struct pf_limit, pf_limits[PF_LIMIT_MAX]); > > #define PACKET_LOOPED(pd) ((pd)->pf_mtag && \ > @@ -359,15 +357,13 @@ > > SYSCTL_NODE(_net, OID_AUTO, pf, CTLFLAG_RW, 0, "pf(4)"); > > -VNET_DEFINE(u_long, pf_hashsize); > -#define V_pf_hashsize VNET(pf_hashsize) > -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, > - &VNET_NAME(pf_hashsize), 0, "Size of pf(4) states hashtable"); > +u_long pf_hashsize; > +SYSCTL_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, > + &pf_hashsize, 0, "Size of pf(4) states hashtable"); > > -VNET_DEFINE(u_long, pf_srchashsize); > -#define V_pf_srchashsize VNET(pf_srchashsize) > -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, > - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); > +u_long pf_srchashsize; > +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, > + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); > Why do you have to devirtualize these variables? Are per vnet hashtables sizes not useful or do they cause issues? > VNET_DEFINE(void *, pf_swi_cookie); > > @@ -698,12 +694,12 @@ > struct pf_srchash *sh; > u_int i; > > - TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &V_pf_hashsize); > - if (V_pf_hashsize == 0 || !powerof2(V_pf_hashsize)) > - V_pf_hashsize = PF_HASHSIZ; > - TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &V_pf_srchashsize); > - if (V_pf_srchashsize == 0 || !powerof2(V_pf_srchashsize)) > - V_pf_srchashsize = PF_HASHSIZ / 4; > + TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &pf_hashsize); > + if (pf_hashsize == 0 || !powerof2(pf_hashsize)) > + pf_hashsize = PF_HASHSIZ; > + TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &pf_srchashsize); > + if (pf_srchashsize == 0 || !powerof2(pf_srchashsize)) > + pf_srchashsize = PF_HASHSIZ / 4; > > V_pf_hashseed = arc4random(); > > @@ -717,11 +713,11 @@ > V_pf_state_key_z = uma_zcreate("pf state keys", > sizeof(struct pf_state_key), pf_state_key_ctor, NULL, NULL, NULL, > UMA_ALIGN_PTR, 0); > - V_pf_keyhash = malloc(V_pf_hashsize * sizeof(struct pf_keyhash), > + V_pf_keyhash = malloc(pf_hashsize * sizeof(struct pf_keyhash), > M_PFHASH, M_WAITOK | M_ZERO); > - V_pf_idhash = malloc(V_pf_hashsize * sizeof(struct pf_idhash), > + V_pf_idhash = malloc(pf_hashsize * sizeof(struct pf_idhash), > M_PFHASH, M_WAITOK | M_ZERO); > - V_pf_hashmask = V_pf_hashsize - 1; > + V_pf_hashmask = pf_hashsize - 1; > for (i = 0, kh = V_pf_keyhash, ih = V_pf_idhash; i <= V_pf_hashmask; > i++, kh++, ih++) { > mtx_init(&kh->lock, "pf_keyhash", NULL, MTX_DEF); > @@ -735,9 +731,9 @@ > V_pf_limits[PF_LIMIT_SRC_NODES].zone = V_pf_sources_z; > uma_zone_set_max(V_pf_sources_z, PFSNODE_HIWAT); > uma_zone_set_warning(V_pf_sources_z, "PF source nodes limit reached"); > - V_pf_srchash = malloc(V_pf_srchashsize * sizeof(struct pf_srchash), > + V_pf_srchash = malloc(pf_srchashsize * sizeof(struct pf_srchash), > M_PFHASH, M_WAITOK|M_ZERO); > - V_pf_srchashmask = V_pf_srchashsize - 1; > + V_pf_srchashmask = pf_srchashsize - 1; > for (i = 0, sh = V_pf_srchash; i <= V_pf_srchashmask; i++, sh++) > mtx_init(&sh->lock, "pf_srchash", NULL, MTX_DEF); > > @@ -757,13 +753,17 @@ > STAILQ_INIT(&V_pf_sendqueue); > SLIST_INIT(&V_pf_overloadqueue); > TASK_INIT(&V_pf_overloadtask, 0, pf_overload_task, &V_pf_overloadqueue); > - mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF); > - mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL, > - MTX_DEF); > + if (IS_DEFAULT_VNET(curvnet)) { > + mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF); > + mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL, > + MTX_DEF); > + } > > /* Unlinked, but may be referenced rules. */ > TAILQ_INIT(&V_pf_unlinked_rules); > - mtx_init(&pf_unlnkdrules_mtx, "pf unlinked rules", NULL, MTX_DEF); > + if (IS_DEFAULT_VNET(curvnet)) > + mtx_init(&pf_unlnkdrules_mtx, "pf unlinked rules", NULL, MTX_DEF); > + > } "if (IS_DEFAULT_VNET(curvnet))" constructions look a little ugly for me. Isn't possible to split these initialization functions on two parts: one (not "virtualized") to run by pf_load() and the other by vnet_pf_init()? > > void > @@ -1309,68 +1309,35 @@ > pf_purge_thread(void *v) > { > u_int idx = 0; > + VNET_ITERATOR_DECL(vnet_iter); > > - CURVNET_SET((struct vnet *)v); > - > for (;;) { > - PF_RULES_RLOCK(); > - rw_sleep(pf_purge_thread, &pf_rules_lock, 0, "pftm", hz / 10); > + tsleep(pf_purge_thread, PWAIT, "pftm", hz / 10); > + VNET_LIST_RLOCK(); > + VNET_FOREACH(vnet_iter) { > + CURVNET_SET(vnet_iter); > > - if (V_pf_end_threads) { > - /* > - * To cleanse up all kifs and rules we need > - * two runs: first one clears reference flags, > - * then pf_purge_expired_states() doesn't > - * raise them, and then second run frees. > - */ > - PF_RULES_RUNLOCK(); > - pf_purge_unlinked_rules(); > - pfi_kif_purge(); > - > - /* > - * Now purge everything. > - */ > - pf_purge_expired_states(0, V_pf_hashmask); > - pf_purge_expired_fragments(); > - pf_purge_expired_src_nodes(); > - > - /* > - * Now all kifs & rules should be unreferenced, > - * thus should be successfully freed. > - */ > - pf_purge_unlinked_rules(); > - pfi_kif_purge(); > - > - /* > - * Announce success and exit. > - */ > - PF_RULES_RLOCK(); > - V_pf_end_threads++; > - PF_RULES_RUNLOCK(); > - wakeup(pf_purge_thread); > - kproc_exit(0); > - } Running only one instance of pf_purge_thread, which iterates over all vnets looks like a good idea to me, but do we really not need this clean up stuff for our only thread? Don't you have issues e.g. on pf module unload? > - PF_RULES_RUNLOCK(); > - > /* Process 1/interval fraction of the state table every run. */ > idx = pf_purge_expired_states(idx, V_pf_hashmask / > - (V_pf_default_rule.timeout[PFTM_INTERVAL] * 10)); > + (V_pf_default_rule.timeout[PFTM_INTERVAL] * 10)); > > /* Purge other expired types every PFTM_INTERVAL seconds. */ > if (idx == 0) { > - /* > - * Order is important: > - * - states and src nodes reference rules > - * - states and rules reference kifs > - */ > - pf_purge_expired_fragments(); > - pf_purge_expired_src_nodes(); > - pf_purge_unlinked_rules(); > - pfi_kif_purge(); > + /* > + * Order is important: > + * - states and src nodes reference rules > + * - states and rules reference kifs > + */ > + pf_purge_expired_fragments(); > + pf_purge_expired_src_nodes(); > + pf_purge_unlinked_rules(); > + pfi_kif_purge(); This is a good example of unnecessary whitespace noise. > } > + CURVNET_RESTORE(); > + } > + VNET_LIST_RUNLOCK(); > } > /* not reached */ > - CURVNET_RESTORE(); > } > -- Mikolaj Golub From owner-freebsd-pf@FreeBSD.ORG Wed Jun 5 13:54:14 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0063DF04 for ; Wed, 5 Jun 2013 13:54:13 +0000 (UTC) (envelope-from ar.molchanov@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id D63CB1AD1 for ; Wed, 5 Jun 2013 13:54:13 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kq13so1002561pab.26 for ; Wed, 05 Jun 2013 06:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=q/xdTs43Kep+00SfaU0zT1bOiKABsRYvn+D3f3qfqZw=; b=KrwEBNPHk0pycBcsU6FHr+YowaNOUtgQRGE8RDqazKrRjoH650DvfUAfew88dSgZc9 jAkLF30DunPZtQdiiLA/ISutboC2Z+hWxUtq+z8R0wohRYvp1hV5V2wJkODIhetj7OsJ TdIhi2SJeQBqjkOci/cgJvDg4iV13715AARgziAVWlREjaK9trvgcZA1E2dXIH34119g PmsZ9wXDaZ+93S1VytIOZtD0d8Geggmv7k4zE/ds581id6RsMaGCsJFC/hXCgPEvii7N efIpir5DYRBCTguj5osgJYyDo0Y1PtYDO6FuprlggafG3+CJG53HllEICO0PHwB6EuFA 0Udg== X-Received: by 10.66.157.104 with SMTP id wl8mr12286671pab.40.1370440453676; Wed, 05 Jun 2013 06:54:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.30.69 with HTTP; Wed, 5 Jun 2013 06:53:53 -0700 (PDT) From: Artiom Molchanov Date: Wed, 5 Jun 2013 15:53:53 +0200 Message-ID: Subject: Simple config works for a limited time then blocks all To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:54:14 -0000 Hi All, I am trying to make my pf configured in two times. In the beginning of the boot process just load a simple ruleset with only ssh and ICMP ping enabled. Then at the end load full rule set. Full rule set works well, but when I ma trying to test my simple rules (pfctl -f /etc/pf_min.conf) I have a strange behavior: 1. ssh connection is interrupted (normal) 2. I reconnect, it works 3. 1-2 minutes later the connection is cut again, no ping, nothing is accepted on the server. 4. It is still possible to receive rtadvd messages (yes, I am using IPv6) I have 9.0-RELEASE FreeBSD 9.0-RELEASE #5 Here is my rules passed throug pfctl -vnf command: set skip on { lo } set debug loud set block-policy return ext_if = "net0" int_if = "home0" int_net = "home0:network" altq on net0 hfsc bandwidth 850Kb tbrsize 1492 queue { q_voice q_other } queue q_voice bandwidth 64Kb priority 6 hfsc( realtime 128Kb ) queue q_other bandwidth 786Kb priority 5 { q_pri q_std q_low } queue q_pri bandwidth 50% priority 3 hfsc( red realtime 96Kb ) queue q_std bandwidth 30% priority 2 hfsc( red default ) queue q_low bandwidth 20% hfsc( red upperlimit 92% ) block return in all pass out all flags S/SA keep state pass out on net0 proto udp from any to any port 33433 >< 33626 keep state label "UDP TRACEROUTE" pass out inet proto icmp all icmp-type echoreq keep state label "ICMP" pass out inet proto icmp all icmp-type unreach keep state label "ICMP" pass in on net0 inet6 proto ipv6-icmp all icmp6-type echoreq keep state pass in on net0 inet6 proto ipv6-icmp all icmp6-type unreach keep state pass in on net0 inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state pass in on net0 inet6 proto ipv6-icmp all icmp6-type neighbradv keep state pass in on net0 inet6 proto ipv6-icmp all icmp6-type routeradv keep state pass out on net0 inet6 proto ipv6-icmp all icmp6-type echoreq keep state pass out on net0 inet6 proto ipv6-icmp all icmp6-type unreach keep state pass out on net0 inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state pass out on net0 inet6 proto ipv6-icmp all icmp6-type routersol keep state pass out on home0 inet6 proto ipv6-icmp all icmp6-type echoreq keep state pass out on home0 inet6 proto ipv6-icmp all icmp6-type unreach keep state pass out on home0 inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state pass out on home0 inet6 proto ipv6-icmp all icmp6-type neighbradv keep state pass out on home0 inet6 proto ipv6-icmp all icmp6-type routeradv keep state pass in on home0 inet6 proto ipv6-icmp all icmp6-type echoreq keep state pass in on home0 inet6 proto ipv6-icmp all icmp6-type unreach keep state pass in on home0 inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state pass in on home0 inet6 proto ipv6-icmp all icmp6-type routersol keep state pass quick on net0 proto tcp from any to (net0) port = ssh flags S/SA keep state (source-track rule, max-src-conn 10, max-src-conn-rate 5/60, overload flush, src.track 60) queue q_pri pass quick on home0 inet6 proto tcp from 2001:xxxx:xxxx:abc::/64 to (home0)/32 port = ssh flags S/SA keep state pass quick on home0 inet proto tcp from 192.168.17.0/24 to (home0) port = ssh flags S/SA keep state pass inet6 proto tcp from 2001:xxxx:xxxx:abc::/64 to any port = domain flags S/SA keep state pass inet6 proto udp from 2001:xxxx:xxxx:abc::/64 to any port = domain keep state pass inet proto tcp from 192.168.17.0/24 to any port = domain flags S/SA keep state pass inet proto udp from 192.168.17.0/24 to any port = domain keep state From owner-freebsd-pf@FreeBSD.ORG Thu Jun 6 10:36:09 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD93465C; Thu, 6 Jun 2013 10:36:09 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by mx1.freebsd.org (Postfix) with ESMTP id 593C51816; Thu, 6 Jun 2013 10:36:09 +0000 (UTC) Received: from [172.31.0.42] ([85.216.121.245]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Meutp-1V0Akm46gr-00OU2F; Thu, 06 Jun 2013 12:36:08 +0200 Message-ID: <51B065F5.4080209@gmx.com> Date: Thu, 06 Jun 2013 12:35:33 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mikolaj Golub Subject: Re: pf + vimage patch References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> In-Reply-To: <20130605085219.GA53217@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:D++XOwS5R0lcMZ6V04weTtl/e1jFrUz3b2Q08P1soMzHg95wMGR SUvuUkPK5aAZIvOoScAfo8OQyRIXUFRvDrV8xf7fMp4w3V+OcjFx2q+Cp/02Y2H1ZUy5f49 dSUvretEMHOaLoN+BRt06i/RTffplPnrT3jWkOCgyOmdlc1jdSzcricwNb0qM0es0O4YdHb pLy1jCyEhqMsPMYPrxqRQ== Cc: "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:36:09 -0000 Hi, Comments below. On 06/05/2013 10:52 AM, Mikolaj Golub wrote: > 1) It looks like the patch can be split on several parts. A log > message to every change describing why it is needed and what problem > solves would be very helpful. As a tool to maintain such changes I > personally prefer git. I'll try to break it in parts. It should be easy now to break it. Getting familiar with git will need some time so I'll handle it myself this time. > 2) You use spaces for indentation, where tabs should be. This adds > unnecessary noise and makes the patch less readable. Also someone > will need to fix this when eventually committing to the tree. Yes, I wrongly assumed that pf didn't follow style(9) strictly. Will fix that. > 3) When generating diff from svn, adding -x-pu options will make the > diff more readable. Yes indeed, thanks! > Also see some questions/comments below. > >> Index: sys/net/pfvar.h >> =================================================================== >> --- sys/net/pfvar.h (revision 251294) >> +++ sys/net/pfvar.h (working copy) >> @@ -901,7 +901,6 @@ >> struct pf_ruleset *, struct pf_pdesc *, int); >> extern pflog_packet_t *pflog_packet_ptr; >> >> -#define V_pf_end_threads VNET(pf_end_threads) >> #endif /* _KERNEL */ >> >> #define PFSYNC_FLAG_SRCNODE 0x04 >> Index: sys/netpfil/pf/pf.c >> =================================================================== >> --- sys/netpfil/pf/pf.c (revision 251294) >> +++ sys/netpfil/pf/pf.c (working copy) >> @@ -300,8 +300,6 @@ >> >> int in4_cksum(struct mbuf *m, u_int8_t nxt, int off, int len); >> >> -VNET_DECLARE(int, pf_end_threads); >> - >> VNET_DEFINE(struct pf_limit, pf_limits[PF_LIMIT_MAX]); >> >> #define PACKET_LOOPED(pd) ((pd)->pf_mtag && \ >> @@ -359,15 +357,13 @@ >> >> SYSCTL_NODE(_net, OID_AUTO, pf, CTLFLAG_RW, 0, "pf(4)"); >> >> -VNET_DEFINE(u_long, pf_hashsize); >> -#define V_pf_hashsize VNET(pf_hashsize) >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, >> - &VNET_NAME(pf_hashsize), 0, "Size of pf(4) states hashtable"); >> +u_long pf_hashsize; >> +SYSCTL_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, >> + &pf_hashsize, 0, "Size of pf(4) states hashtable"); >> >> -VNET_DEFINE(u_long, pf_srchashsize); >> -#define V_pf_srchashsize VNET(pf_srchashsize) >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, >> - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); >> +u_long pf_srchashsize; >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, >> + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); >> > > Why do you have to devirtualize these variables? Are per vnet > hashtables sizes not useful or do they cause issues? Per VNET variables are not useful for pf_hashsize and pf_srchashsize since these values are RO and cannot be modified at runtime. >> VNET_DEFINE(void *, pf_swi_cookie); >> >> @@ -698,12 +694,12 @@ >> struct pf_srchash *sh; >> u_int i; >> >> - TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &V_pf_hashsize); >> - if (V_pf_hashsize == 0 || !powerof2(V_pf_hashsize)) >> - V_pf_hashsize = PF_HASHSIZ; >> - TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &V_pf_srchashsize); >> - if (V_pf_srchashsize == 0 || !powerof2(V_pf_srchashsize)) >> - V_pf_srchashsize = PF_HASHSIZ / 4; >> + TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &pf_hashsize); >> + if (pf_hashsize == 0 || !powerof2(pf_hashsize)) >> + pf_hashsize = PF_HASHSIZ; >> + TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &pf_srchashsize); >> + if (pf_srchashsize == 0 || !powerof2(pf_srchashsize)) >> + pf_srchashsize = PF_HASHSIZ / 4; >> >> V_pf_hashseed = arc4random(); >> >> @@ -717,11 +713,11 @@ >> V_pf_state_key_z = uma_zcreate("pf state keys", >> sizeof(struct pf_state_key), pf_state_key_ctor, NULL, NULL, NULL, >> UMA_ALIGN_PTR, 0); >> - V_pf_keyhash = malloc(V_pf_hashsize * sizeof(struct pf_keyhash), >> + V_pf_keyhash = malloc(pf_hashsize * sizeof(struct pf_keyhash), >> M_PFHASH, M_WAITOK | M_ZERO); >> - V_pf_idhash = malloc(V_pf_hashsize * sizeof(struct pf_idhash), >> + V_pf_idhash = malloc(pf_hashsize * sizeof(struct pf_idhash), >> M_PFHASH, M_WAITOK | M_ZERO); >> - V_pf_hashmask = V_pf_hashsize - 1; >> + V_pf_hashmask = pf_hashsize - 1; >> for (i = 0, kh = V_pf_keyhash, ih = V_pf_idhash; i <= V_pf_hashmask; >> i++, kh++, ih++) { >> mtx_init(&kh->lock, "pf_keyhash", NULL, MTX_DEF); >> @@ -735,9 +731,9 @@ >> V_pf_limits[PF_LIMIT_SRC_NODES].zone = V_pf_sources_z; >> uma_zone_set_max(V_pf_sources_z, PFSNODE_HIWAT); >> uma_zone_set_warning(V_pf_sources_z, "PF source nodes limit reached"); >> - V_pf_srchash = malloc(V_pf_srchashsize * sizeof(struct pf_srchash), >> + V_pf_srchash = malloc(pf_srchashsize * sizeof(struct pf_srchash), >> M_PFHASH, M_WAITOK|M_ZERO); >> - V_pf_srchashmask = V_pf_srchashsize - 1; >> + V_pf_srchashmask = pf_srchashsize - 1; >> for (i = 0, sh = V_pf_srchash; i <= V_pf_srchashmask; i++, sh++) >> mtx_init(&sh->lock, "pf_srchash", NULL, MTX_DEF); >> >> @@ -757,13 +753,17 @@ >> STAILQ_INIT(&V_pf_sendqueue); >> SLIST_INIT(&V_pf_overloadqueue); >> TASK_INIT(&V_pf_overloadtask, 0, pf_overload_task, &V_pf_overloadqueue); >> - mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF); >> - mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL, >> - MTX_DEF); >> + if (IS_DEFAULT_VNET(curvnet)) { >> + mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF); >> + mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL, >> + MTX_DEF); >> + } >> >> /* Unlinked, but may be referenced rules. */ >> TAILQ_INIT(&V_pf_unlinked_rules); >> - mtx_init(&pf_unlnkdrules_mtx, "pf unlinked rules", NULL, MTX_DEF); >> + if (IS_DEFAULT_VNET(curvnet)) >> + mtx_init(&pf_unlnkdrules_mtx, "pf unlinked rules", NULL, MTX_DEF); >> + >> } > > "if (IS_DEFAULT_VNET(curvnet))" constructions look a little ugly for > me. Isn't possible to split these initialization functions on two > parts: one (not "virtualized") to run by pf_load() and the other by > vnet_pf_init()? It is indeed ugly. I was trying not to diverse to much from the original code. I will do it properly. >> >> void >> @@ -1309,68 +1309,35 @@ >> pf_purge_thread(void *v) >> { >> u_int idx = 0; >> + VNET_ITERATOR_DECL(vnet_iter); >> >> - CURVNET_SET((struct vnet *)v); >> - >> for (;;) { >> - PF_RULES_RLOCK(); >> - rw_sleep(pf_purge_thread, &pf_rules_lock, 0, "pftm", hz / 10); >> + tsleep(pf_purge_thread, PWAIT, "pftm", hz / 10); >> + VNET_LIST_RLOCK(); >> + VNET_FOREACH(vnet_iter) { >> + CURVNET_SET(vnet_iter); >> >> - if (V_pf_end_threads) { >> - /* >> - * To cleanse up all kifs and rules we need >> - * two runs: first one clears reference flags, >> - * then pf_purge_expired_states() doesn't >> - * raise them, and then second run frees. >> - */ >> - PF_RULES_RUNLOCK(); >> - pf_purge_unlinked_rules(); >> - pfi_kif_purge(); >> - >> - /* >> - * Now purge everything. >> - */ >> - pf_purge_expired_states(0, V_pf_hashmask); >> - pf_purge_expired_fragments(); >> - pf_purge_expired_src_nodes(); >> - >> - /* >> - * Now all kifs & rules should be unreferenced, >> - * thus should be successfully freed. >> - */ >> - pf_purge_unlinked_rules(); >> - pfi_kif_purge(); >> - >> - /* >> - * Announce success and exit. >> - */ >> - PF_RULES_RLOCK(); >> - V_pf_end_threads++; >> - PF_RULES_RUNLOCK(); >> - wakeup(pf_purge_thread); >> - kproc_exit(0); >> - } > > Running only one instance of pf_purge_thread, which iterates over all > vnets looks like a good idea to me, but do we really not need this > clean up stuff for our only thread? Don't you have issues e.g. on pf > module unload? module unload is broken:( Maybe it can be fixed at a (bit) later date? >> - PF_RULES_RUNLOCK(); >> - >> /* Process 1/interval fraction of the state table every run. */ >> idx = pf_purge_expired_states(idx, V_pf_hashmask / >> - (V_pf_default_rule.timeout[PFTM_INTERVAL] * 10)); >> + (V_pf_default_rule.timeout[PFTM_INTERVAL] * 10)); >> >> /* Purge other expired types every PFTM_INTERVAL seconds. */ >> if (idx == 0) { >> - /* >> - * Order is important: >> - * - states and src nodes reference rules >> - * - states and rules reference kifs >> - */ >> - pf_purge_expired_fragments(); >> - pf_purge_expired_src_nodes(); >> - pf_purge_unlinked_rules(); >> - pfi_kif_purge(); >> + /* >> + * Order is important: >> + * - states and src nodes reference rules >> + * - states and rules reference kifs >> + */ >> + pf_purge_expired_fragments(); >> + pf_purge_expired_src_nodes(); >> + pf_purge_unlinked_rules(); >> + pfi_kif_purge(); > > This is a good example of unnecessary whitespace noise. will fix these. >> } >> + CURVNET_RESTORE(); >> + } >> + VNET_LIST_RUNLOCK(); >> } >> /* not reached */ >> - CURVNET_RESTORE(); >> } >> > Thank you for your comments. I was informed by bz@ that there is a security issue with pf being exposed in a jail, so I'll start from there and then will continue with your comments. Nikos From owner-freebsd-pf@FreeBSD.ORG Thu Jun 6 12:24:17 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 14C80278; Thu, 6 Jun 2013 12:24:17 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id E611F1DE6; Thu, 6 Jun 2013 12:24:15 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id r7so1570276bkg.31 for ; Thu, 06 Jun 2013 05:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=eIZGnFUwokq+esK0tN2UdK4DZfTSBmtRPjlpxKUkiq0=; b=tiXxjS0oPRWCZjUWM041S7SLylnm9facT8wCnDGt5gNO54dPQWTrqTh2DDDBAxmfIV lnIU+Fu3R2b9PcADqugtJxT4U2GZfmDV0F0X0FOxPtKbkeinb4LzHteEtxf2gaEn8c04 MXNl2K29EcP6b9jr6ZpS9alpaoEvh8usMLP+f2ozljqhsYjV2J4XF5x2NTVdsIGC+YZD uN5yRngJQPgXiNcCZBsrhUX8jkZRJXpPvThK0u6yB3g72u9vRpjHnEnr8sOpOrBB4QpW NVWjc2teC25pPMeFeuCFHDsFHEJTfqOQDo8Nl53E/Mrw6UJxyrEkWkb1ewFD6qr0SkcA LpbA== X-Received: by 10.204.72.137 with SMTP id m9mr634498bkj.122.1370521454805; Thu, 06 Jun 2013 05:24:14 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id fz10sm27756318bkc.9.2013.06.06.05.24.12 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 06 Jun 2013 05:24:13 -0700 (PDT) Sender: Mikolaj Golub Date: Thu, 6 Jun 2013 15:24:10 +0300 From: Mikolaj Golub To: Nikos Vassiliadis Subject: Re: pf + vimage patch Message-ID: <20130606122409.GA10459@gmail.com> References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> <51B065F5.4080209@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B065F5.4080209@gmx.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 12:24:17 -0000 On Thu, Jun 06, 2013 at 12:35:33PM +0200, Nikos Vassiliadis wrote: > >> -VNET_DEFINE(u_long, pf_srchashsize); > >> -#define V_pf_srchashsize VNET(pf_srchashsize) > >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, > >> - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); > >> +u_long pf_srchashsize; > >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, > >> + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); > >> > > > > Why do you have to devirtualize these variables? Are per vnet > > hashtables sizes not useful or do they cause issues? > > Per VNET variables are not useful for pf_hashsize and pf_srchashsize > since these values are RO and cannot be modified at runtime. Indeed. I missed RDTUN flag. > module unload is broken:( Maybe it can be fixed at a (bit) later date? I don't think Gleb will be happy with this. Some time ago he removed some vimage related stuff to prevent crashing on module unload (see r229849). Actually your patch looks like a partial revert of that commit. So I think you need to think about this issue from start. At least it should not crash non-vimage kernel and there should be understanding how to fix it for vimage kernel. Your approach with keeping only one purge thread might make it simpler. -- Mikolaj Golub From owner-freebsd-pf@FreeBSD.ORG Thu Jun 6 12:28:58 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 45AA838E; Thu, 6 Jun 2013 12:28:58 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 629C61E29; Thu, 6 Jun 2013 12:28:57 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r56CSuta046057; Thu, 6 Jun 2013 16:28:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r56CSuQL046056; Thu, 6 Jun 2013 16:28:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 6 Jun 2013 16:28:55 +0400 From: Gleb Smirnoff To: Mikolaj Golub Subject: Re: pf + vimage patch Message-ID: <20130606122855.GC14667@glebius.int.ru> References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> <51B065F5.4080209@gmx.com> <20130606122409.GA10459@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130606122409.GA10459@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-jail@freebsd.org, "Bjoern A. Zeeb" , freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 12:28:58 -0000 On Thu, Jun 06, 2013 at 03:24:10PM +0300, Mikolaj Golub wrote: M> > >> -VNET_DEFINE(u_long, pf_srchashsize); M> > >> -#define V_pf_srchashsize VNET(pf_srchashsize) M> > >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, M> > >> - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); M> > >> +u_long pf_srchashsize; M> > >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, M> > >> + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); M> > >> M> > > M> > > Why do you have to devirtualize these variables? Are per vnet M> > > hashtables sizes not useful or do they cause issues? M> > M> > Per VNET variables are not useful for pf_hashsize and pf_srchashsize M> > since these values are RO and cannot be modified at runtime. M> M> Indeed. I missed RDTUN flag. M> M> > module unload is broken:( Maybe it can be fixed at a (bit) later date? M> M> I don't think Gleb will be happy with this. Some time ago he removed M> some vimage related stuff to prevent crashing on module unload (see M> r229849). Actually your patch looks like a partial revert of that M> commit. So I think you need to think about this issue from start. At M> least it should not crash non-vimage kernel and there should be M> understanding how to fix it for vimage kernel. Your approach with M> keeping only one purge thread might make it simpler. True. It is very much appreciated that you are working on vimage + pf, but breaking module unload isn't an option. When hacking on a part of kernel, having a possibility to avoid a reboot after each compile is very important. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Thu Jun 6 13:30:44 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D14C6BE3; Thu, 6 Jun 2013 13:30:44 +0000 (UTC) (envelope-from titi5187@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 765361198; Thu, 6 Jun 2013 13:30:44 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id s9so7105216iec.30 for ; Thu, 06 Jun 2013 06:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GSpRu686kn7cS675oheBZtUm+9tcakEOjGvbZuLM0C0=; b=hpYiz3ocl2invRhNmAVQ450cz/9DVr0t64JMHDT9tZRPZ6wVMTgXj20YOFrx7SzFqN WhkSo6UkhAILyYyCpRGcIIxdzLTc/lqWCq7LmSUI7tKm0tmUlXgI1lR2cuNdQ9f14BKz v7TQ+UWXVAEDCU65W5J4OwhOGbqoQtxCiNV+xoM7HnY+kCzRi8Ydw9Vu4gKVdwDwTHFY lZf7om2JcUPu0R1PrWRjO/qpD+HyZ4wKtrbX+/uhMRJ/gKoKCjbi4P9/6cXf/BQPFJ5F wa0XPHCqmBAaRVkFkQnreAq54HwDmfPmdQ/k+16g/wufoIH44XoNlttwTLSrNM/LaqGz vwYw== MIME-Version: 1.0 X-Received: by 10.50.47.105 with SMTP id c9mr5808925ign.50.1370525444206; Thu, 06 Jun 2013 06:30:44 -0700 (PDT) Received: by 10.64.89.71 with HTTP; Thu, 6 Jun 2013 06:30:44 -0700 (PDT) In-Reply-To: <20130606122855.GC14667@glebius.int.ru> References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> <51B065F5.4080209@gmx.com> <20130606122409.GA10459@gmail.com> <20130606122855.GC14667@glebius.int.ru> Date: Thu, 6 Jun 2013 15:30:44 +0200 Message-ID: Subject: Re: pf + vimage patch From: Thibault Noel To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Mikolaj Golub , "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:30:44 -0000 Hi, I quite agree with Gleb Smirnoff on the possibility of avoiding a reboot after each compile. I don't now if it's a good moment to speak of this, but I observed that if pfsync is active in the kernel, it will use its state table even if nothing is set in the rc.conf. I think that if no parameters is written in the rc.conf (syncpeer, etc. ..) it will not be usefull to create lock to block the state table thus it will slow pf. What do you think ? 2013/6/6 Gleb Smirnoff > On Thu, Jun 06, 2013 at 03:24:10PM +0300, Mikolaj Golub wrote: > M> > >> -VNET_DEFINE(u_long, pf_srchashsize); > M> > >> -#define V_pf_srchashsize VNET(pf_srchashsize) > M> > >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, > CTLFLAG_RDTUN, > M> > >> - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes > hashtable"); > M> > >> +u_long pf_srchashsize; > M> > >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, > CTLFLAG_RDTUN, > M> > >> + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); > M> > >> > M> > > > M> > > Why do you have to devirtualize these variables? Are per vnet > M> > > hashtables sizes not useful or do they cause issues? > M> > > M> > Per VNET variables are not useful for pf_hashsize and pf_srchashsize > M> > since these values are RO and cannot be modified at runtime. > M> > M> Indeed. I missed RDTUN flag. > M> > M> > module unload is broken:( Maybe it can be fixed at a (bit) later date? > M> > M> I don't think Gleb will be happy with this. Some time ago he removed > M> some vimage related stuff to prevent crashing on module unload (see > M> r229849). Actually your patch looks like a partial revert of that > M> commit. So I think you need to think about this issue from start. At > M> least it should not crash non-vimage kernel and there should be > M> understanding how to fix it for vimage kernel. Your approach with > M> keeping only one purge thread might make it simpler. > > True. It is very much appreciated that you are working on vimage + pf, > but breaking module unload isn't an option. > > When hacking on a part of kernel, having a possibility to avoid a reboot > after each compile is very important. > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to " > freebsd-virtualization-unsubscribe@freebsd.org" > From owner-freebsd-pf@FreeBSD.ORG Thu Jun 6 16:47:17 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A36CEEC; Thu, 6 Jun 2013 16:47:17 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id A7C0F1D9A; Thu, 6 Jun 2013 16:47:16 +0000 (UTC) Received: from [172.31.0.42] ([85.216.121.245]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M6ilI-1UPe5B3EJQ-00wXDy; Thu, 06 Jun 2013 18:47:10 +0200 Message-ID: <51B0BD05.60102@gmx.com> Date: Thu, 06 Jun 2013 18:47:01 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: pf + vimage patch References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> <51B065F5.4080209@gmx.com> <20130606122409.GA10459@gmail.com> <20130606122855.GC14667@glebius.int.ru> In-Reply-To: <20130606122855.GC14667@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:yLPARyYTKHkkRyMtMbsVYPXLJmfa+iUwAGfyu/gWFigeoljAbek VURb4qnVbCeCSutaraVeR5+cQsGY6dqwta+KHp2Lhpkc6jc+4Ns8Ov8aCm9ARWdepLnqwvq j/Z9aJIJ/x21zUjY5JgwGE1dA4TOgBZeCHVhGulJQH3SYRQNvT0LpyINMl/H+xpcFUBVc0s jHUNEiKxYm0gHLIptgxGQ== Cc: Mikolaj Golub , "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:47:17 -0000 On 06/06/2013 02:28 PM, Gleb Smirnoff wrote: > M> > module unload is broken:( Maybe it can be fixed at a (bit) later date? > M> > M> I don't think Gleb will be happy with this. Some time ago he removed > M> some vimage related stuff to prevent crashing on module unload (see > M> r229849). Actually your patch looks like a partial revert of that > M> commit. So I think you need to think about this issue from start. At > M> least it should not crash non-vimage kernel and there should be > M> understanding how to fix it for vimage kernel. Your approach with > M> keeping only one purge thread might make it simpler. Unloading should be simple in the non-vimage case as well - I think. > True. It is very much appreciated that you are working on vimage + pf, > but breaking module unload isn't an option. > > When hacking on a part of kernel, having a possibility to avoid a reboot > after each compile is very important. > Good point. Thank you both for your comments. Nikos From owner-freebsd-pf@FreeBSD.ORG Sat Jun 8 14:11:40 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5BCB446B for ; Sat, 8 Jun 2013 14:11:40 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id 058351B26 for ; Sat, 8 Jun 2013 14:11:40 +0000 (UTC) Received: from [192.168.44.130] ([80.237.234.148]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MWwp6-1UqqCK03MK-00W0P9 for ; Sat, 08 Jun 2013 16:11:36 +0200 Message-ID: <51B33B8B.9050006@gmx.com> Date: Sat, 08 Jun 2013 16:11:23 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: de-virtualize pf sysctls Content-Type: multipart/mixed; boundary="------------090806000609060806010909" X-Provags-ID: V03:K0:U4Rttue2ha4cYHfYqRORWPaOUuWA5S4DTnbkF76H00PmCmdlxBQ khFIhtW8rsrKWWQOQ+19f9gwkjrw6ArcQa45z8OqMURGvQD2MCI68l+lxrDwtVNLVQudMjj ihUca606mZvOHi4M0l3ENYxL1DNhBEuk9dZaWLBHAMeqbrfUck/+mD0h09SZc534VYvc5K7 e/zIj3xxRht1N0+dvxV/Q== X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 14:11:40 -0000 This is a multi-part message in MIME format. --------------090806000609060806010909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Please review this patch. These two variables are RO-tunables and cannot be changed at runtime. As such, it is not useful to virtualize them. Thanks, Nikos --------------090806000609060806010909 Content-Type: text/plain; charset=UTF-8; name="pf.patch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pf.patch.txt" Index: sys/netpfil/pf/pf.c =================================================================== --- sys/netpfil/pf/pf.c (revision 251514) +++ sys/netpfil/pf/pf.c (working copy) @@ -359,15 +359,13 @@ VNET_DEFINE(u_long, pf_srchashmask); SYSCTL_NODE(_net, OID_AUTO, pf, CTLFLAG_RW, 0, "pf(4)"); -VNET_DEFINE(u_long, pf_hashsize); -#define V_pf_hashsize VNET(pf_hashsize) -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, - &VNET_NAME(pf_hashsize), 0, "Size of pf(4) states hashtable"); +static u_long pf_hashsize; +static u_long pf_srchashsize; -VNET_DEFINE(u_long, pf_srchashsize); -#define V_pf_srchashsize VNET(pf_srchashsize) +SYSCTL_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, + &pf_hashsize, 0, "Size of pf(4) states hashtable"); SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); VNET_DEFINE(void *, pf_swi_cookie); @@ -698,12 +696,12 @@ pf_initialize() struct pf_srchash *sh; u_int i; - TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &V_pf_hashsize); - if (V_pf_hashsize == 0 || !powerof2(V_pf_hashsize)) - V_pf_hashsize = PF_HASHSIZ; - TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &V_pf_srchashsize); - if (V_pf_srchashsize == 0 || !powerof2(V_pf_srchashsize)) - V_pf_srchashsize = PF_HASHSIZ / 4; + TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &pf_hashsize); + if (pf_hashsize == 0 || !powerof2(pf_hashsize)) + pf_hashsize = PF_HASHSIZ; + TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &pf_srchashsize); + if (pf_srchashsize == 0 || !powerof2(pf_srchashsize)) + pf_srchashsize = PF_HASHSIZ / 4; V_pf_hashseed = arc4random(); @@ -717,11 +715,11 @@ pf_initialize() V_pf_state_key_z = uma_zcreate("pf state keys", sizeof(struct pf_state_key), pf_state_key_ctor, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); - V_pf_keyhash = malloc(V_pf_hashsize * sizeof(struct pf_keyhash), + V_pf_keyhash = malloc(pf_hashsize * sizeof(struct pf_keyhash), M_PFHASH, M_WAITOK | M_ZERO); - V_pf_idhash = malloc(V_pf_hashsize * sizeof(struct pf_idhash), + V_pf_idhash = malloc(pf_hashsize * sizeof(struct pf_idhash), M_PFHASH, M_WAITOK | M_ZERO); - V_pf_hashmask = V_pf_hashsize - 1; + V_pf_hashmask = pf_hashsize - 1; for (i = 0, kh = V_pf_keyhash, ih = V_pf_idhash; i <= V_pf_hashmask; i++, kh++, ih++) { mtx_init(&kh->lock, "pf_keyhash", NULL, MTX_DEF); @@ -735,9 +733,9 @@ pf_initialize() V_pf_limits[PF_LIMIT_SRC_NODES].zone = V_pf_sources_z; uma_zone_set_max(V_pf_sources_z, PFSNODE_HIWAT); uma_zone_set_warning(V_pf_sources_z, "PF source nodes limit reached"); - V_pf_srchash = malloc(V_pf_srchashsize * sizeof(struct pf_srchash), + V_pf_srchash = malloc(pf_srchashsize * sizeof(struct pf_srchash), M_PFHASH, M_WAITOK|M_ZERO); - V_pf_srchashmask = V_pf_srchashsize - 1; + V_pf_srchashmask = pf_srchashsize - 1; for (i = 0, sh = V_pf_srchash; i <= V_pf_srchashmask; i++, sh++) mtx_init(&sh->lock, "pf_srchash", NULL, MTX_DEF); --------------090806000609060806010909-- From owner-freebsd-pf@FreeBSD.ORG Sat Jun 8 14:50:35 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 75FFA1236 for ; Sat, 8 Jun 2013 14:50:35 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id 21B2C1F16 for ; Sat, 8 Jun 2013 14:50:35 +0000 (UTC) Received: from [192.168.44.130] ([80.237.234.148]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M1WHV-1UVjWt1S9p-00tVSW for ; Sat, 08 Jun 2013 16:50:34 +0200 Message-ID: <51B344B8.9090109@gmx.com> Date: Sat, 08 Jun 2013 16:50:32 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: Re: de-virtualize pf sysctls References: <51B33B8B.9050006@gmx.com> In-Reply-To: <51B33B8B.9050006@gmx.com> Content-Type: multipart/mixed; boundary="------------020102060004090405000206" X-Provags-ID: V03:K0:1Zp9f2q/Xx+942eZgJz68zbcra5bEIE0Y45HdkCg6gcUNC6ncEL 0yQgV6zYTEm7Y0Q4FPrtLY0oHSmahj6kkZNMKQDMakRrm+RlO56MhnzuFe96vMafykLPe9K TMg6nw2A1gg0fs8l4PTKraehjE1FvYI1EZcUq4Esa//eezzdH3nACkvQ+Sq9biLyUKXxRhL T1vsIFDj5JVang8K7ykkg== X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 14:50:35 -0000 This is a multi-part message in MIME format. --------------020102060004090405000206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/08/2013 04:11 PM, Nikos Vassiliadis wrote: > Hi, > > Please review this patch. These two variables are RO-tunables and > cannot be changed at runtime. As such, it is not useful to > virtualize them. Sorry for the noise, I missed something in the previous patch. --------------020102060004090405000206 Content-Type: text/plain; charset=UTF-8; name="pf.patch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pf.patch.txt" Index: sys/netpfil/pf/pf.c =================================================================== --- sys/netpfil/pf/pf.c (revision 251514) +++ sys/netpfil/pf/pf.c (working copy) @@ -359,15 +359,13 @@ VNET_DEFINE(u_long, pf_srchashmask); SYSCTL_NODE(_net, OID_AUTO, pf, CTLFLAG_RW, 0, "pf(4)"); -VNET_DEFINE(u_long, pf_hashsize); -#define V_pf_hashsize VNET(pf_hashsize) -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, - &VNET_NAME(pf_hashsize), 0, "Size of pf(4) states hashtable"); +static u_long pf_hashsize; +static u_long pf_srchashsize; -VNET_DEFINE(u_long, pf_srchashsize); -#define V_pf_srchashsize VNET(pf_srchashsize) -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); +SYSCTL_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, + &pf_hashsize, 0, "Size of pf(4) states hashtable"); +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); VNET_DEFINE(void *, pf_swi_cookie); @@ -698,12 +696,12 @@ pf_initialize() struct pf_srchash *sh; u_int i; - TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &V_pf_hashsize); - if (V_pf_hashsize == 0 || !powerof2(V_pf_hashsize)) - V_pf_hashsize = PF_HASHSIZ; - TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &V_pf_srchashsize); - if (V_pf_srchashsize == 0 || !powerof2(V_pf_srchashsize)) - V_pf_srchashsize = PF_HASHSIZ / 4; + TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &pf_hashsize); + if (pf_hashsize == 0 || !powerof2(pf_hashsize)) + pf_hashsize = PF_HASHSIZ; + TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &pf_srchashsize); + if (pf_srchashsize == 0 || !powerof2(pf_srchashsize)) + pf_srchashsize = PF_HASHSIZ / 4; V_pf_hashseed = arc4random(); @@ -717,11 +715,11 @@ pf_initialize() V_pf_state_key_z = uma_zcreate("pf state keys", sizeof(struct pf_state_key), pf_state_key_ctor, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); - V_pf_keyhash = malloc(V_pf_hashsize * sizeof(struct pf_keyhash), + V_pf_keyhash = malloc(pf_hashsize * sizeof(struct pf_keyhash), M_PFHASH, M_WAITOK | M_ZERO); - V_pf_idhash = malloc(V_pf_hashsize * sizeof(struct pf_idhash), + V_pf_idhash = malloc(pf_hashsize * sizeof(struct pf_idhash), M_PFHASH, M_WAITOK | M_ZERO); - V_pf_hashmask = V_pf_hashsize - 1; + V_pf_hashmask = pf_hashsize - 1; for (i = 0, kh = V_pf_keyhash, ih = V_pf_idhash; i <= V_pf_hashmask; i++, kh++, ih++) { mtx_init(&kh->lock, "pf_keyhash", NULL, MTX_DEF); @@ -735,9 +733,9 @@ pf_initialize() V_pf_limits[PF_LIMIT_SRC_NODES].zone = V_pf_sources_z; uma_zone_set_max(V_pf_sources_z, PFSNODE_HIWAT); uma_zone_set_warning(V_pf_sources_z, "PF source nodes limit reached"); - V_pf_srchash = malloc(V_pf_srchashsize * sizeof(struct pf_srchash), + V_pf_srchash = malloc(pf_srchashsize * sizeof(struct pf_srchash), M_PFHASH, M_WAITOK|M_ZERO); - V_pf_srchashmask = V_pf_srchashsize - 1; + V_pf_srchashmask = pf_srchashsize - 1; for (i = 0, sh = V_pf_srchash; i <= V_pf_srchashmask; i++, sh++) mtx_init(&sh->lock, "pf_srchash", NULL, MTX_DEF); --------------020102060004090405000206--