Date: Wed, 7 Dec 2016 17:06:41 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: Marcel Moolenaar <marcel@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r309394 - head/sys/netpfil/pf Message-ID: <A2B9B009-CA11-4AA0-AC26-DDDB122B1746@xcllnt.net> In-Reply-To: <20161207210824.GN27748@FreeBSD.org> References: <201612020615.uB26Fxs1049431@repo.freebsd.org> <20161207210824.GN27748@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Dec 7, 2016, at 1:08 PM, Gleb Smirnoff <glebius@FreeBSD.org = <mailto:glebius@FreeBSD.org>> 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 <mailto:marcel@xcllnt.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A2B9B009-CA11-4AA0-AC26-DDDB122B1746>