RELENG_8 pf stack issue (state count spiraling out of control)

Daniel Hartmeier daniel at benzedrine.cx
Tue May 3 10:39:53 UTC 2011


On Mon, May 02, 2011 at 06:58:54PM -0700, Jeremy Chadwick wrote:

> The next thing I tried was "/etc/rc.d/pf stop", which worked.  Then I
> did "/etc/rc.d/pf start", which also worked.  However, what I saw next
> surely indicated a bug in the pf layer somewhere -- "pfctl -s states"
> and "pfctl -s info" disagreed on the state count:

This can be explained. Note that "/etc/rc.d/pf start" does first flush
all states by calling pfctl -F all.

This calls pf_unlink_state() for every state in the kernel, which
marks each state with PFTM_UNLINKED, but doesn't free it yet.

Such states do not show up in pfctl -s state output, but are still
counted in pfctl -s info output. Normally, they are freed the next
time the pfpurge thread runs (once per second).

It looks like the pfpurge thread was either

  a) sleeping indefinitely, not returning once a second from

	tsleep(pf_purge_thread, PWAIT, "pftm", 1 * hz);

     or

  b) constantly failing to acquire a lock with

	if (!sx_try_upgrade(&pf_consistency_lock))
		return (0);

Maybe a) is possible when CLOCK_MONOTONIC is decreasing? And the
"POKED TIMER" messages you get from BIND, too?

Kind regards,
Daniel


More information about the freebsd-pf mailing list