From owner-freebsd-pf@FreeBSD.ORG Sun Mar 10 04:31:45 2013 Return-Path: Delivered-To: freebsd-pf@smarthost.ysv.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 24ABAA56; Sun, 10 Mar 2013 04:31:45 +0000 (UTC) (envelope-from linimon@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 D9D4AB16; Sun, 10 Mar 2013 04:31:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2A4Viwa036544; Sun, 10 Mar 2013 04:31:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2A4Vi0D036543; Sun, 10 Mar 2013 04:31:44 GMT (envelope-from linimon) Date: Sun, 10 Mar 2013 04:31:44 GMT Message-Id: <201303100431.r2A4Vi0D036543@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/176763: [pf] [patch] Removing pf Source entries locks kernel. 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: Sun, 10 Mar 2013 04:31:45 -0000 Old Synopsis: Removing pf Source entries locks kernel. New Synopsis: [pf] [patch] Removing pf Source entries locks kernel. Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 10 04:31:13 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=176763 From owner-freebsd-pf@FreeBSD.ORG Mon Mar 11 11:06:47 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 72512B2C for ; Mon, 11 Mar 2013 11:06:47 +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 63CD67D4 for ; Mon, 11 Mar 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2BB6lrb089092 for ; Mon, 11 Mar 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2BB6k8L089089 for freebsd-pf@FreeBSD.org; Mon, 11 Mar 2013 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Mar 2013 11:06:46 GMT Message-Id: <201303111106.r2BB6k8L089089@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, 11 Mar 2013 11:06:47 -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/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 50 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Mar 11 15:05:23 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 47F70458 for ; Mon, 11 Mar 2013 15:05:23 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id CE9BB969 for ; Mon, 11 Mar 2013 15:05:22 +0000 (UTC) Received: by mail-bk0-f43.google.com with SMTP id jm19so1723743bkc.16 for ; Mon, 11 Mar 2013 08:05:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id:x-gm-message-state; bh=yAHTqpZ6wezuRuGmMIXuJGzSYgIfGrRrmf5SQT3CVVY=; b=fmJp1TQZ1yI7NE/sMQHcTjGrPzmCV8Axim0zczMYZl5GmpxkTpNlbPRfFldcosNqy1 yLnuYRIZt/LnqVL7ax9EL1nb8+SgYnsE0BZ03Oe4JS2J3xUlJZX8n4/rj4JzWVfylIU1 ZVfmt0cdq+w/lS/WG4wMWBxMRk8cMB38uZaUpyrrssulJmm7XVn2mnVhx4lUeZztI3AW 3dq7SR6PDkZBPzfUToneF1QKiOyT76miQZgfRV7/TUtPCTqblDOiheJ/xB5FeUxDlRin iVAffk/VXgsN+XEM+VfHcOckRWWlJPhbSbqoSM+blIuAia/9bUnBgOarQ5JA6vlzhHJ/ qu6g== X-Received: by 10.204.195.133 with SMTP id ec5mr4731790bkb.32.1363014321478; Mon, 11 Mar 2013 08:05:21 -0700 (PDT) Received: from zvezda.localnet ([212.48.107.10]) by mx.google.com with ESMTPS id g28sm4198353bkv.17.2013.03.11.08.05.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 11 Mar 2013 08:05:20 -0700 (PDT) From: Kajetan Staszkiewicz To: Ermal =?iso-8859-1?q?Lu=E7i?= Subject: Re: [patch] Source entries removing is awfully slow. Date: Mon, 11 Mar 2013 16:05:19 +0100 User-Agent: KMail/1.13.5 (Linux/3.6.6-vegeta.1; KDE/4.4.5; x86_64; ; ) References: <201303081419.17743.vegeta@tuxpowered.net> <201303091437.51945.vegeta@tuxpowered.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201303111605.19518.vegeta@tuxpowered.net> X-Gm-Message-State: ALoCoQnp6UN9mymlIWBQC07dD6TXVu6U/AcHuXOSkS7Tl5PJQ9zRFLKdHWd0he2o9bzN+5OdPeO9 Cc: "freebsd-net@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: Mon, 11 Mar 2013 15:05:23 -0000 There are some things I find flawed in your patch: 1. +#if 0 if (killed > 0) pf_purge_expired_src_nodes(1); +#endif This means that after using `pfctl -K` the src nodes are still around until purged and any new states created will still use them and bump their expire timer. This also changes behavior from DIOCCLRSRCNODES, which also performs the purge immediately. You also moved s->src_node=s->nat_src_node=NULL code to inside of pf_purge_expired_src_nodes, therefore I believe it should be called immediately. If detaching state from source is done in pf_purge_expired_src_nodes, DIOCCLRSRCNODES does not have to traverse the state table anymore, so we achieve another performance improvement. 2. /* Handle state to src_node linkage */ +#ifndef __FreeBSD__ if (sn->states != 0) { RB_FOREACH(s, pf_state_tree_id, #ifdef __FreeBSD__ &V_tree_id) { #else &tree_id) { #endif if (s->src_node == sn) s->src_node = NULL; if (s->nat_src_node == sn) s->nat_src_node = NULL; } sn->states = 0; } +#endif sn->expire = 1; killed++; This removes a bit too much code, that is zeroing of source's state counter. Please find the next version of the patch here: http://vegeta.tuxpowered.net/download/link-states-to-src_node-3.patch This one also takes care of removing states linked to found sources if pfctl is given extra -c parameter (that can stand for "clear", I could not find any other free pfctl parameter better matching). Thanks to this parameter, the default behavior is not changed. -- | pozdrawiam / greetings | powered by Debian, CentOS and FreeBSD | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' From owner-freebsd-pf@FreeBSD.ORG Mon Mar 11 15:27:36 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 A9DC7A5D; Mon, 11 Mar 2013 15:27:36 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 468D4A47; Mon, 11 Mar 2013 15:27:35 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id nd7so2325310qeb.24 for ; Mon, 11 Mar 2013 08:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mJaK4Fg2x2PZ9Tq04oPGZOgMA3o+ot3/feS5TJ+sB0M=; b=EFOvUgDYK27zjJJHQhsKNuvEYDY4bUymODKafmtN01FlvtQnlNK+LogfbJBOhe61Ic z6rUy708j0aWy+LLpF6FZLTazgDGqVFtHAx5wKI7cQgqxTi2uZb2bDuL0PiK4qB7d4+H aUKQ/HmrUmv4coS+/n2hwVLqzbENWNRI1Kgczi/qT6qcaqejtjgzZpmZTcdGJZwnSg/e C3/GEAxoWdlVn/EWL2g6MWw/+/pv0AM72luqvtWB4TOFE9uVdUKJdP+nhTu1wh3tVzqf WuZquHcAYIZ5caecS0t7DAzgHCjAYaATwvya/FUmAn7UC6vAhhS7QKup4ZI/FTDdexhD 2PcA== MIME-Version: 1.0 X-Received: by 10.229.69.24 with SMTP id x24mr4030045qci.16.1363015653965; Mon, 11 Mar 2013 08:27:33 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.27.197 with HTTP; Mon, 11 Mar 2013 08:27:33 -0700 (PDT) In-Reply-To: <201303111605.19518.vegeta@tuxpowered.net> References: <201303081419.17743.vegeta@tuxpowered.net> <201303091437.51945.vegeta@tuxpowered.net> <201303111605.19518.vegeta@tuxpowered.net> Date: Mon, 11 Mar 2013 16:27:33 +0100 X-Google-Sender-Auth: u_ysQLfDXzv2yicH4zsprTPBp9c Message-ID: Subject: Re: [patch] Source entries removing is awfully slow. From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Kajetan Staszkiewicz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@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: Mon, 11 Mar 2013 15:27:36 -0000 On Mon, Mar 11, 2013 at 4:05 PM, Kajetan Staszkiewicz wrote: > There are some things I find flawed in your patch: > > 1. > > +#if 0 > if (killed > 0) > pf_purge_expired_src_nodes(1); > +#endif > > This means that after using `pfctl -K` the src nodes are still around until > purged and any new states created will still use them and bump their expire > timer. This also changes behavior from DIOCCLRSRCNODES, which also > performs the > purge immediately. You also moved s->src_node=s->nat_src_node=NULL code to > inside of pf_purge_expired_src_nodes, therefore I believe it should be > called > immediately. If detaching state from source is done in > pf_purge_expired_src_nodes, DIOCCLRSRCNODES does not have to traverse the > state > table anymore, so we achieve another performance improvement. > Well probably just need to clear the rtaddr member of a source node. Its an optimization to keep the source node there until next purge since you would avoid a memory allocation. It seems to me a better behaviour rather than having to loop N amount of states during an ioctl which is supposed to be fast. You need to take into consideration that an ioctl freezes the whole operation of network in this case because you are modifying the core of pf(4). I would rather be keen to mark a src_node state as expired and let the purge_thread collect that? > > 2. > /* Handle state to src_node linkage */ > +#ifndef __FreeBSD__ > if (sn->states != 0) { > RB_FOREACH(s, pf_state_tree_id, > #ifdef __FreeBSD__ > &V_tree_id) { > #else > &tree_id) { > #endif > if (s->src_node == sn) > s->src_node = NULL; > if (s->nat_src_node == sn) > s->nat_src_node = NULL; > } > sn->states = 0; > } > +#endif > sn->expire = 1; > killed++; > > This removes a bit too much code, that is zeroing of source's state > counter. > > Please find the next version of the patch here: > http://vegeta.tuxpowered.net/download/link-states-to-src_node-3.patch > > This one also takes care of removing states linked to found sources if > pfctl is > given extra -c parameter (that can stand for "clear", I could not find any > other free pfctl parameter better matching). Thanks to this parameter, the > default behavior is not changed. > > Its ok for the extra -c, there is even -S free just to be consistent with the flush and vieweing options probably better use that?! The addition of 2 extra members to pf_state structure i am reluctant a bit since its just for reporting the number of states killed and it really is not a useful information compared to the increased size of the structure that consumes RAM memory. Also pf_src_node structure if the 2 options for display are not added can use the member that is used to report the number of states killed to request killing linked states. What do you think? > -- > | pozdrawiam / greetings | powered by Debian, CentOS and FreeBSD | > | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | > | Vegeta | www: http://vegeta.tuxpowered.net | > `------------------------^---------------------------------------' > -- Ermal From owner-freebsd-pf@FreeBSD.ORG Mon Mar 11 16:51:21 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 8F25C87B for ; Mon, 11 Mar 2013 16:51:21 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4D8F84 for ; Mon, 11 Mar 2013 16:51:20 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id i18so1801592bkv.32 for ; Mon, 11 Mar 2013 09:51:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id:x-gm-message-state; bh=WXjJkv9LY0P3kftCOg/sWVzJR7yEN9eks/TjFAt1hsA=; b=YPXC/ME9LbwZnwC0UtAzJEPSMcnaPIssWaHXIWcWTj0N33sZMjHvU54wVvGdap4/fj rZZB1NiuvOW6hWMw3SAnVaKXod0go3Ynt1CNeaZUrvKlgJahaglPifGRVSOmeCzX6ehZ lec/69GSEHRuMvRltiUeh66AHTxihaFiYvh7rN4XH7LthBFwoinE3QqUrHRkdaOehXen KIXehpwa8u6mhcQHMxEqt89G70P1Jypt7VLrIKlToc8Cf/pGivVeSxkP+5CdIAG0l5U3 hJ6LYfhBpZxnQWU2soMteB82V2X3BpGn8fi7orpnSHPgG66PPa3bBJpFd1x7So3Gv4jM Wxug== X-Received: by 10.205.122.80 with SMTP id gf16mr4973231bkc.130.1363020680024; Mon, 11 Mar 2013 09:51:20 -0700 (PDT) Received: from zvezda.localnet ([212.48.107.10]) by mx.google.com with ESMTPS id v2sm4339726bkw.5.2013.03.11.09.51.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 11 Mar 2013 09:51:19 -0700 (PDT) From: Kajetan Staszkiewicz To: Ermal =?utf-8?q?Lu=C3=A7i?= Subject: Re: [patch] Source entries removing is awfully slow. Date: Mon, 11 Mar 2013 17:51:18 +0100 User-Agent: KMail/1.13.5 (Linux/3.6.6-vegeta.1; KDE/4.4.5; x86_64; ; ) References: <201303081419.17743.vegeta@tuxpowered.net> <201303111605.19518.vegeta@tuxpowered.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201303111751.18274.vegeta@tuxpowered.net> X-Gm-Message-State: ALoCoQmc5QXaIgxmksN3rzTt++CdVJCmQpkybFkJVWmfh28h2G+MeJ5E8Nad0iaL6+6jSaOwzcqD Cc: "freebsd-net@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: Mon, 11 Mar 2013 16:51:21 -0000 Dnia poniedzia=C5=82ek, 11 marca 2013 o 16:27:33 Ermal Lu=C3=A7i napisa=C5= =82(a): > On Mon, Mar 11, 2013 at 4:05 PM, Kajetan Staszkiewicz > =20 > > wrote: > >=20 > > There are some things I find flawed in your patch: > >=20 > > 1. > >=20 > > +#if 0 > >=20 > > if (killed > 0) > > =20 > > pf_purge_expired_src_nodes(1); > >=20 > > +#endif > >=20 > > This means that after using `pfctl -K` the src nodes are still around > > until purged and any new states created will still use them and bump > > their expire timer. This also changes behavior from DIOCCLRSRCNODES, > > which also performs the > > purge immediately. You also moved s->src_node=3Ds->nat_src_node=3DNULL = code > > to inside of pf_purge_expired_src_nodes, therefore I believe it should > > be called > > immediately. If detaching state from source is done in > > pf_purge_expired_src_nodes, DIOCCLRSRCNODES does not have to traverse t= he > > state > > table anymore, so we achieve another performance improvement. >=20 > Well probably just need to clear the rtaddr member of a source node. rt_addr is a property of pf_state (or did you mean raddr of pf_src_node?), = I do=20 not know if the rest of pf code allows it to be just cleared, and even if, = it=20 would only create broken State entries not forwarding data to the server be= hind=20 the loadbalancer (I *might* want to leave existing connections alive, depen= ding=20 on usage of further mentioned pfctl's "-c" switch, but I always want to rem= ove=20 Sources ASAP so no new connections use them). And of course I prefer to kee= p=20 the default behavior unchanged. > Its an optimization to keep the source node there until next purge since > you would avoid a memory allocation. > It seems to me a better behaviour rather than having to loop N amount of > states during an ioctl which is supposed to be fast. This was the original behavior of the code, I only reduced N to reasonable= =20 values (and therefore time of operation). > You need to take into consideration that an ioctl freezes the whole > operation of network in this case because you are modifying > the core of pf(4). Yes, this is why I started working on the issue in the first place. My appr= oach=20 introduces no additional overhead, only redurces the existing one. > I would rather be keen to mark a src_node state as expired and let the > purge_thread collect that? What I observed was that without calling pf_purge_expired_src_nodes (your=20 patch), Sources were still displayed with 0 expiration time and if any clie= nt=20 connected before they got purged, expiration time was bumped up and the Sou= rce=20 entry was alive again and never purged anymore. This is definetely not the= =20 behavior I'd expect. >=20 > > 2. > >=20 > > /* Handle state to src_node linkage */ > >=20 > > +#ifndef __FreeBSD__ > >=20 > > if (sn->states !=3D 0) { > > =20 > > RB_FOREACH(s, pf_state_tree_id, > >=20 > > #ifdef __FreeBSD__ > >=20 > > &V_tree_id) { > >=20 > > #else > >=20 > > &tree_id) { > >=20 > > #endif > >=20 > > if (s->src_node =3D=3D sn) > > =20 > > s->src_node =3D NULL; > > =20 > > if (s->nat_src_node =3D=3D sn) > > =20 > > s->nat_src_node =3D NULL; > > =20 > > } > > sn->states =3D 0; > > =20 > > } > >=20 > > +#endif > >=20 > > sn->expire =3D 1; > > killed++; > >=20 > > This removes a bit too much code, that is zeroing of source's state > > counter. > >=20 > > Please find the next version of the patch here: > > http://vegeta.tuxpowered.net/download/link-states-to-src_node-3.patch > >=20 > > This one also takes care of removing states linked to found sources if > > pfctl is > > given extra -c parameter (that can stand for "clear", I could not find > > any other free pfctl parameter better matching). Thanks to this > > parameter, the default behavior is not changed. >=20 > Its ok for the extra -c, there is even -S free just to be consistent with > the flush and vieweing options probably better use that?! > The addition of 2 extra members to pf_state structure i am reluctant a bit > since its just for reporting the number of states killed > and it really is not a useful information compared to the increased size = of > the structure that consumes RAM memory. Variable for counting terminated states was added to pfioc_src_node_kill, n= ot=20 to pf_state. > Also pf_src_node structure if the 2 options for display are not added can > use the member that is used to report > the number of states killed to request killing linked states. > What do you think? Again, the counter is in pfioc_src_node_kill, not pf_src_node. =2D-=20 | pozdrawiam / greetings | powered by Debian, CentOS and FreeBSD | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' From owner-freebsd-pf@FreeBSD.ORG Wed Mar 13 15:51:06 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 CEE7843F for ; Wed, 13 Mar 2013 15:51:06 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 485ECE6 for ; Wed, 13 Mar 2013 15:51:06 +0000 (UTC) Received: by mail-bk0-f41.google.com with SMTP id q16so550386bkw.0 for ; Wed, 13 Mar 2013 08:51:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id:x-gm-message-state; bh=F6yqG1/38K14avVxMvRqadOiK8R1IAZXFddoi4E4v7Q=; b=BFLpe8RGkbxGX8Px0q1sj/1aPmsKvBxgP7wKxy+2Gv6XNuAW8+pKl4lDoXnxoW8z79 FOTcLvWm2b1FoIkJ0oDfTuqUbBi3HTa3MWq1DHlTuQ20dU1wiec8ueSRyBxscDfPuqla xE6xsmSzhS+qEh8XhzPPfdlmNEcfVyV5bJShvXQDm8uH6L6X9wLepKdaXqRmf5MTXwgJ lRtwplKUqA7aUnFpn1BybC41/48QE6xOiEGdb8tidx1os5ZOphVJOIBVcMJ2qWXiFGo5 B46FBW0NvIFbCaIlbf7bltwWHbp387jvxL7elO5RbPqSnJNseGGmvyHvWmOzAwiY7Gfm ZMsQ== X-Received: by 10.204.238.133 with SMTP id ks5mr7923229bkb.101.1363189865108; Wed, 13 Mar 2013 08:51:05 -0700 (PDT) Received: from zvezda.localnet ([212.48.107.10]) by mx.google.com with ESMTPS id o2sm6185337bkv.3.2013.03.13.08.51.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Mar 2013 08:51:04 -0700 (PDT) From: Kajetan Staszkiewicz To: Ermal =?iso-8859-1?q?Lu=E7i?= Subject: Re: [patch] Source entries removing is awfully slow. Date: Wed, 13 Mar 2013 16:51:03 +0100 User-Agent: KMail/1.13.5 (Linux/3.6.6-vegeta.1; KDE/4.4.5; x86_64; ; ) References: <201303081419.17743.vegeta@tuxpowered.net> <201303111751.18274.vegeta@tuxpowered.net> In-Reply-To: <201303111751.18274.vegeta@tuxpowered.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201303131651.03250.vegeta@tuxpowered.net> X-Gm-Message-State: ALoCoQlV33zAGuz5PcvnaXY10vJvz1Do4Y4U4/qOzktWEFBUHkME5tDTD7HowzNV3P7ugSFvBuuf Cc: "freebsd-net@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, 13 Mar 2013 15:51:06 -0000 I managed to run your patch on production machine and it produced panic in a few seconds after network traffic was directed through it. The difference I spotted is that you insert the State entry to state_list near the end of pf_create_state: @@ -3950,8 +3970,18 @@ pf_create_state(struct pf_rule *r, struc pool_put(&pf_state_pl, s); #endif return (PF_DROP); +#ifdef __FreeBSD__ + } else { + if (sn != NULL) + TAILQ_INSERT_HEAD(&sn->state_list, s, srcnode_link); + if (nsn != NULL) + TAILQ_INSERT_HEAD(&nsn->state_list, s, srcnode_link); + *sm = s; + } +#else } else *sm = s; +#endif while my original aproach was to do it much earlier. The working version is: @@ -3895,12 +3915,18 @@ pf_create_state(struct pf_rule *r, struc if (sn != NULL) { s->src_node = sn; s->src_node->states++; +#ifdef __FreeBSD__ + TAILQ_INSERT_HEAD(&sn->state_list, s, srcnode_link); +#endif } if (nsn != NULL) { /* XXX We only modify one side for now. */ PF_ACPY(&nsn->raddr, &nk->addr[1], pd->af); s->nat_src_node = nsn; s->nat_src_node->states++; +#ifdef __FreeBSD__ + TAILQ_INSERT_HEAD(&nsn->state_list, s, srcnode_link); +#endif } if (pd->proto == IPPROTO_TCP) { if ((pd->flags & PFDESC_TCP_NORM) && pf_normalize_tcp_init(m, backtrace: #7 0xffffffff810d7d2a in pf_src_tree_remove_state (s=0xfffffe007bfd55f0) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:1564 #8 0xffffffff810e01c2 in pf_test_rule (rm=0xffffff862f6ec848, sm=0xffffff862f6ec840, direction=2, kif=0xfffffe000ab67400, m=0xfffffe0070be9500, off=20, h=0xfffffe0070be9580, pd=0xffffff862f6ec780, am=0xffffff862f6ec850, rsm=0xffffff862f6ec838, ifq=0x0, inp=0x0) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:3965 #9 0xffffffff810e1d26 in pf_test (dir=2, ifp=Variable "ifp" is not available. ) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6964 #10 0xffffffff810e8cc1 in pf_check_out (arg=Variable "arg" is not available. ) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:4187 #11 0xffffffff8078816e in pfil_run_hooks (ph=Variable "ph" is not available. ) at /usr/src/sys/net/pfil.c:82 #12 0xffffffff807a20f5 in ip_fastforward (m=0xfffffe0070be9500) at /usr/src/sys/netinet/ip_fastfwd.c:445 contrib/pf/net/pf.c:3965 3961 if (pf_state_insert(BOUND_IFACE(r, kif), skw, sks, s)) { 3962 if (pd->proto == IPPROTO_TCP) 3963 pf_normalize_tcp_cleanup(s); 3964 REASON_SET(&reason, PFRES_STATEINS); 3965 pf_src_tree_remove_state(s); 3966 STATE_DEC_COUNTERS(s); 3967 #ifdef __FreeBSD__ 3968 pool_put(&V_pf_state_pl, s); 3969 #else 3970 pool_put(&pf_state_pl, s); 3971 #endif 3972 return (PF_DROP); contrib/pf/net/pf.c:1564 1561 } 1562 #ifdef __FreeBSD__ 1563 if (!TAILQ_EMPTY(&s->nat_src_node->state_list)) 1564 TAILQ_REMOVE(&s->nat_src_node->state_list, s, srcnode_link); 1565 #endif 1566 } 1567 s->src_node = s->nat_src_node = NULL; Following s -> nat_src_node -> state_list: state_list = {tqh_first = 0xfffffe01fe360130, tqh_last = 0x0} s and nat_src_node seem ok for me, not any memory garbage, e.g. they have proper creation and expiration times. Do we hit a src_node that has the state_list uninitialised, and performing an early insert automatically fixes it? -- | pozdrawiam / greetings | powered by Debian, CentOS and FreeBSD | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' From owner-freebsd-pf@FreeBSD.ORG Wed Mar 13 18:06:04 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 5D907C89 for ; Wed, 13 Mar 2013 18:06:04 +0000 (UTC) (envelope-from russ@quist.ca) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 29DCAB52 for ; Wed, 13 Mar 2013 18:06:04 +0000 (UTC) Received: by mail-yh0-f41.google.com with SMTP id 47so223860yhr.28 for ; Wed, 13 Mar 2013 11:06:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=FtQzBZmFtLqxUTcRiICLKc0OO0xKhj6WCbfz/USf8d4=; b=YiReSNpvi+jcwrtQkcr36UESRAkSidnUz23lPCnnD/Js0jQJx4biA6HmgAormyjQ6L o2kLQon7YJVycYtYbWfMZG/T/UMRzhYrLcINE4nkklKN2i2kdm8/otFdBTRRu4FWM9v6 AVVjVmbCG6WZX3CWyvTCAVoCjZDQ70ksTRkZhGo22QylWWaFuxYDBqgBpelWzmpzMl3j VAA942nVpdky1X13WDW8B6AdWJ+opCv6fW5kTYukFlDNN3MwEoDtctOEkJBvTWpRTOWz 8XKJpAn7jJG8SY7v9/0ZCSKLP/h+NLGayADz9nwPwqeZ0NoU+ZOqinFtAL5Wp6mOxfRO kW3w== MIME-Version: 1.0 X-Received: by 10.236.128.42 with SMTP id e30mr16719144yhi.7.1363197963711; Wed, 13 Mar 2013 11:06:03 -0700 (PDT) Received: by 10.101.10.7 with HTTP; Wed, 13 Mar 2013 11:06:03 -0700 (PDT) Date: Wed, 13 Mar 2013 12:06:03 -0600 Message-ID: Subject: Versions From: Russell Sutherland To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkXwbn23FxSEaStA6pHTjCPy/1OdPTO2ua52KR+amy6NFiSVa7XpcKF7kViJ1vd4n9Tiwsj 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, 13 Mar 2013 18:06:04 -0000 Which version (OpenBSD numbering) of pf is found in FreeBSD 9.1? -- Russell Sutherland email: russ@quist.ca cell: +1.416.803.0080 From owner-freebsd-pf@FreeBSD.ORG Wed Mar 13 18:10:34 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 D2ACFE5D for ; Wed, 13 Mar 2013 18:10:34 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id A2F6AC1E for ; Wed, 13 Mar 2013 18:10:34 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so1879220ieb.31 for ; Wed, 13 Mar 2013 11:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=lEWvj77PitkCktjAo5DVkyg/NcQJrfc+UoRShw3DCKk=; b=Jg+5nRZGSruVnJpa4UITcrs+wNzfxiNwcSv8MbmZ6ZfOrsEc+aAXjR3BeQ8QNu/ITl xMRNJ3q5GSddlOn1mZIf1WMYfP+Vusg0qp7bFroWLGVzxMLz2Dn3AMah2wV8uq46CjZH d3UQ56gaWwNeuwbafjK0B0+diom9kjIysmVQs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=lEWvj77PitkCktjAo5DVkyg/NcQJrfc+UoRShw3DCKk=; b=LGnFLuCKGrh3l3ZH8ueG77sb/65+lHIrYf3OC11IX7BUqzoea41CdFfs6zcxCFz/vb kpIPNSdcvyLoVLEYVg9uTUMsVEn5XEK+bSaMltd6CcQOnen/BZRXNwX1jufD71XzBP5L C5bkMzrgKK/kYv2spszZS2heaaa5O3bxsfqsvejehlVywo636PoVk8bRE75SL+9WHcY4 uUhjJiBSU1IXCCN6VnUmTQIuZpeizCdA4GuUWNDdQe5THHsVLrQ6nMXLohS2gwNbIfqS g26TwwewUpEIjDmye94rUT3igK7o3zAVTlrf6kNnElQLI52itvc+rxLMkleEAdcxTqPq 6ewQ== X-Received: by 10.50.46.197 with SMTP id x5mr17060926igm.7.1363198234327; Wed, 13 Mar 2013 11:10:34 -0700 (PDT) Received: from [192.168.32.77] (24-231-147-188.dhcp.aldl.mi.charter.com. [24.231.147.188]) by mx.google.com with ESMTPS id in10sm5934539igc.1.2013.03.13.11.10.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 11:10:32 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <87E292CA-919D-437D-93FD-C11A5CAC904A@DataIX.net> X-Mailer: iPhone Mail (10B146) From: Jason Hellenthal Subject: Re: Versions Date: Wed, 13 Mar 2013 14:10:29 -0400 To: Russell Sutherland X-Gm-Message-State: ALoCoQlmkcwSKFKP71IzD2xX0XIZImOmpmf4g5lryyBswjmQvFE6NkKQFmLOjX+2k6bTD6DOx3xY Cc: "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, 13 Mar 2013 18:10:34 -0000 Correct me if I'm wrong but 4.5 -- Jason Hellenthal JJH48-ARIN - (2^(N-1)) On Mar 13, 2013, at 14:06, Russell Sutherland wrote: > Which version (OpenBSD numbering) of pf is found in FreeBSD 9.1? > > -- > Russell Sutherland > email: russ@quist.ca > cell: +1.416.803.0080 > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"