From owner-svn-src-all@freebsd.org Thu Dec 8 01:06:41 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DA04C6B4A0; Thu, 8 Dec 2016 01:06:41 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 818B31DB7; Thu, 8 Dec 2016 01:06:41 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from [192.168.2.21] (atc.xcllnt.net [50.0.150.213]) by mail.xcllnt.net (8.15.2/8.15.2) with ESMTPS id uB8167q5017072 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Dec 2016 17:06:40 -0800 (PST) (envelope-from marcel@xcllnt.net) From: Marcel Moolenaar Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r309394 - head/sys/netpfil/pf Date: Wed, 7 Dec 2016 17:06:41 -0800 In-Reply-To: <20161207210824.GN27748@FreeBSD.org> Cc: Marcel Moolenaar , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org To: Gleb Smirnoff References: <201612020615.uB26Fxs1049431@repo.freebsd.org> <20161207210824.GN27748@FreeBSD.org> X-Mailer: Apple Mail (2.3251) X-Greylist: Sender IP whitelisted, ACL 39 matched, not delayed by milter-greylist-4.6.1 (mail.xcllnt.net [50.0.150.214]); Wed, 07 Dec 2016 17:06:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 01:06:41 -0000 > On Dec 7, 2016, at 1:08 PM, Gleb Smirnoff > wrote: >=20 > Marcel, >=20 > thanks for the fixes. While the problem with the first chunk > in pfsync_sendout() is obvious, the problem you are fixing in th > second chunk in the pfsync_delete_state() is not clear to me. > Can you please explain what scenario are you fixing there? State updates may be pending for state being deleted. This means that the state is still sitting on either the PFSYNC_S_UPD or PFSYNC_S_UPD_C queues. What pfsync(4) does in that case is simply remove the state from those queues and add it to the PFSYNC_S_DEL queue. But, pf(4) has already dropped the reference count for state that=E2=80=99s deleted and the only reference is by pfsync(4) by virtue of being on the PFSYNC_S_UPD or PFSYNC_S_UPD_C queues. When the state gets dequeued from those queues, the reference count drops to 0 and the state is deleted (read: memory freed). But the same state is subsequently added to the PFSYNC_S_DEL queue =E2=80=94 i.e. after the memory was freed. HTH, --=20 Marcel Moolenaar marcel@xcllnt.net