Re: network locking strategy questions

[Beverly Schwartz <bschwart%bbn.com@localhost>]

On Mar 12, 2013, at 4:09 AM, David Laight wrote:

> On Mon, Mar 11, 2013 at 09:58:42PM -0400, Beverly Schwartz wrote:
>> 
>> I am asking, because with FAST_IPSEC and multi-core enabled, there
>> is a not-so-slow leak of MCL clusters.
> 
> Sometimes it can be helpful to identify the contents of the
> leaked items.
> Finding one can be tricky, but if the leak is bad enough any random
> piece of memory will eventually be filled with the leaking item.

I am leaking from mclpl.  mclpl has a limit, so once mclpl hits its
limit, functions which use mclpl stop working, but everything else
still runs.  Once in that state, using vmstat -m, one can observe
the rising failure rate for mclpl requests.

Since mclpl has its own API, it is easy to find every place
that uses mclpl.  However, what's not so easy is finding where
members from mclpl are not being released as expected.  I
keep going back to having something to do with locking strategy,
that some sort of conflict is happening which causes mclpl
entries to not be freed when they normally would.  Running
single-core, this does not occur at all.  Using KAME_IPSEC,
this doesn't happen at all.  Next tests I run, I will turn off
altq and pf to see if those are a factor in this.  altq and
pf do not cause a problem if there is *no* active tunnel.

-Bev