From owner-freebsd-pf@freebsd.org Sat Aug 18 22:16:07 2018 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 531831077821 for ; Sat, 18 Aug 2018 22:16:07 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2EF679AFB for ; Sat, 18 Aug 2018 22:16:06 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: by mail-ed1-x534.google.com with SMTP id o8-v6so6380601edt.13 for ; Sat, 18 Aug 2018 15:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxpowered-net.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version; bh=Vz3HenC0xYAK/PS6waZX4PmDOmP99iPft8Q+2p+V4Ck=; b=tPAw0RuszcBpf4hyx3D5bpIKu1H4FvaHf9o0GKsDKjfGt/G+SnCirRZeDtCYL19zhv /+eRhHw5yeUy/Ab5b7Gv6hEhG/XPnCtzUQ3bj0nwCRlV2u2qIUS5dAO1JYvMIMeFHP6Z D37qyXtlflJpdlJ64hGyCUFQ7Bf0blmalpxOHFRqdbUIF89t5OT0xfYS/uAJp8eZSBNu noc9N5cvH6/cFcCHtTjaIea5QJTKWqt8Liyt/jDVo007N+ZTYOl/NQR5mTDcOY6AGpoh vchB3GHvPyw/EO+Hr/H3M+6KQHGgmtBXKoQsQI3Rn9jMD1ysZ2qqfVMJLnU/3hWkPTKx 842A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version; bh=Vz3HenC0xYAK/PS6waZX4PmDOmP99iPft8Q+2p+V4Ck=; b=TppzysCMBue0jxs+r/tRe1BbRoVXtDKlBwGv2o0FZZZWpYIQmDql/QvXiMxQFnU6ix sTMRdbB3sdeIrCfAhBTwSSDj8MNkzyChH+o7KgnOHxWeezLBZbMPJrl3/1tI7Jwj2/2+ 7I/5MBG7XQtvaedn9q53ljRnPWTanZ8sPEFnJe727f6ibjURLlkLTqyMKhvyb6lVMMs7 9Q5/mhIlAknf1xS7qZoqIJWrG9kpFWSZo/vDpSkz+lqecF/Mz95qzwOc5w0tGl6hwJFX mu9I8RXbF85H7YzIFus0FcPmFJnvnxc5BHwZ8YqDILX/iSTH+g/eoAMxj2BcAWTGuOaW X6ng== X-Gm-Message-State: AOUpUlHAEctu4G9wMPgSb4VkAjJvK2G/8UZ3D7HYP/2Tj/pKRgCOgr8g uL2hsnhgdhdL5X29kpoWzcfyIlwkf8c= X-Google-Smtp-Source: AA+uWPw+E4QX7ZmSy0rU7IG+59U3ySpgiRhWgGq5z8xoagIVLNACzN2d/iX91/gMyyxGlj4EHlV1kQ== X-Received: by 2002:aa7:d142:: with SMTP id r2-v6mr47916806edo.286.1534630565508; Sat, 18 Aug 2018 15:16:05 -0700 (PDT) Received: from energia.localnet ([2a02:8108:50bf:d514::5]) by smtp.gmail.com with ESMTPSA id p20-v6sm3080092edr.12.2018.08.18.15.16.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Aug 2018 15:16:04 -0700 (PDT) From: Kajetan Staszkiewicz To: Kristof Provost Cc: freebsd-pf@freebsd.org Subject: Re: pf tables locking Date: Sun, 19 Aug 2018 00:15:58 +0200 Message-ID: <1831273.qCtLAga6ZT@energia> Organization: tuxpowered.net User-Agent: KMail/5.2.3 (Linux/4.16.0-16.2-liquorix-amd64; KDE/5.28.0; x86_64; ; ) In-Reply-To: <18F24996-29D6-4792-BCB7-88738F756077@FreeBSD.org> References: <8680316.SccKl5VnxN@energia> <18F24996-29D6-4792-BCB7-88738F756077@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5655015.LPuHGhcovh"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.27 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, 18 Aug 2018 22:16:07 -0000 --nextPart5655015.LPuHGhcovh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 13 August 2018 15:22:33 CEST Kristof Provost wrote: > > This function is called from pf_test only after PF_RULES_RUNLOCK(). >=20 > I think you=E2=80=99re right, this does look wrong. >=20 > It=E2=80=99s very unlikely that this will actually lead to a crash, becau= se > rules (and associated tables) won=E2=80=99t just go away while there=E2= =80=99s still > state, but we could theoretically lose memory (in the pfrke_counters > allocation), and miscount. >=20 > I don=E2=80=99t want to re-take the rules lock for this But what about things other than counters and disappearing tables, that is= =20 getting addresses out of pool in pf_map_addr? I understand that rpool can't= =20 change live because it changes only with loading a ruleset. But then there = is=20 pfr_pool_get. This one operates totally unlocked. I proposed a patch lockin= g=20 pools in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230640 but now= as I=20 see it locking of each table seems necessary. Why not have granular locking for each pool (or maybe rule) and for each=20 table? =2D-=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' --nextPart5655015.LPuHGhcovh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQSOEQZObv2B8mf0JbnjtFCvbXs6FAUCW3iangAKCRDjtFCvbXs6 FPG4AJ4mSh2S9rFxP3NwQlDz1CG9unGiYgCguljhbuVzV9AdKgp3dJDypNo2AvE= =jpec -----END PGP SIGNATURE----- --nextPart5655015.LPuHGhcovh--