Date: Wed, 7 Nov 2012 07:30:40 +0000 (UTC) From: Gleb Smirnoff <glebius@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r242693 - head/sys/netpfil/pf Message-ID: <201211070730.qA77UeK7075686@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: glebius Date: Wed Nov 7 07:30:40 2012 New Revision: 242693 URL: http://svnweb.freebsd.org/changeset/base/242693 Log: It may happen that pfsync holds the last reference on a state. In this case keys had already been freed. If encountering such state, then just release last reference. Not sure this can happen as a runtime race, but can be reproduced by the following scenario: - enable pfsync - disable pfsync - wait some time - enable pfsync Modified: head/sys/netpfil/pf/if_pfsync.c Modified: head/sys/netpfil/pf/if_pfsync.c ============================================================================== --- head/sys/netpfil/pf/if_pfsync.c Wed Nov 7 07:00:59 2012 (r242692) +++ head/sys/netpfil/pf/if_pfsync.c Wed Nov 7 07:30:40 2012 (r242693) @@ -1545,6 +1545,16 @@ pfsync_sendout(int schedswi) KASSERT(st->sync_state == q, ("%s: st->sync_state == q", __func__)); + if (st->timeout == PFTM_UNLINKED) { + /* + * This happens if pfsync was once + * stopped, and then re-enabled + * after long time. Theoretically + * may happen at usual runtime, too. + */ + pf_release_state(st); + continue; + } /* * XXXGL: some of write methods do unlocked reads * of state data :(
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201211070730.qA77UeK7075686>