Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 May 2011 12:39:50 +0200
From:      Daniel Hartmeier <daniel@benzedrine.cx>
To:        Jeremy Chadwick <freebsd@jdc.parodius.com>
Cc:        freebsd-stable@freebsd.org, freebsd-pf@freebsd.org
Subject:   Re: RELENG_8 pf stack issue (state count spiraling out of control)
Message-ID:  <20110503103950.GD9657@insomnia.benzedrine.cx>
In-Reply-To: <20110503015854.GA31444@icarus.home.lan>
References:  <20110503015854.GA31444@icarus.home.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110503103950.GD9657>