way to disable NSS's memory pool?

[Andrew Cagney]

Hi,

Is there a way, similar to how Electric Fence never releases memory,
to get NSS to never reuse pointers?
(for the moment I'm going around hobbling free calls such as for symkeys).

We (libreswan) are chasing a potential lock contention problem (for
instance, NSC_DeriveKey() -> PR_Lock() appears in an off-cpu profile).
But the water is being muddied by NSS re-using objects and locks so
we'd like to eliminate that.

Andrew

[Robert Relyea]

So there are a couple of types of reuse:

1) using the same pointer for the same object, so, for example, when NSS
returns a slot, it returns a reference to that slot, so searches for the
same slot will always return the same pointer. You free your reference
to that slot. This kind of reuse is pretty fundamental in NSS, and you
really can't do anything about it.

2) reusing keys and session objects. After you free a key or session
object, that object is placed on a free list because a number of things
that you create with the object (like the session or the locks), could
be fairly expensive and key creation/destruction can happen quite
frequently. This can of reuse can be capped, though we may need to add
some machinery to allow applications to cap them.

How many freed key structures that are kept around is determined by the
maxKeyCount variable in the slot. Unfortunately we currently have no way
to set it from the application. It's set based on the token's
maxKeySessionCount in it's tokenInfo structure. Typically it's '0',
which sets maxKeyCount to 800. Sounds like you would like a call that
will set that value to 0 for your tests. That will change the timing of
things (since PK11_SymKeyFree() and creating new keys will both take
longer), but it would reduce the noise of reuse... particularly lock reuse.


bob

[Andrew Cagney]

On Wed, 18 Feb 2026 at 16:32, 'Robert Relyea' via
dev-tec...@mozilla.org <dev-tec...@mozilla.org> wrote:

> 2) reusing keys and session objects. After you free a key or session
> object, that object is placed on a free list because a number of things
> that you create with the object (like the session or the locks), could
> be fairly expensive and key creation/destruction can happen quite
> frequently. This can of reuse can be capped, though we may need to add
> some machinery to allow applications to cap them.
>
> How many freed key structures that are kept around is determined by the
> maxKeyCount variable in the slot. Unfortunately we currently have no way
> to set it from the application. It's set based on the token's
> maxKeySessionCount in it's tokenInfo structure. Typically it's '0',
> which sets maxKeyCount to 800. Sounds like you would like a call that
> will set that value to 0 for your tests. That will change the timing of
> things (since PK11_SymKeyFree() and creating new keys will both take
> longer), but it would reduce the noise of reuse... particularly lock reuse.

Thanks for the pointer! I'll just hack my local build.

The code is also churning through a lot of temp symkeys, I wonder if
it hits the 800 limit.

[Robert Relyea]

> The code is also churning through a lot of temp symkeys, I wonder if
> it hits the 800 limit.

The 800 is how many keys stay on the free list before NSS starts freeing
the keys. It would take quite a feat to hit that limit. You need to
create over 800 symkeys and then free them all to hit the limit. Doing
800 cycles is unlikely to hit the limit if you are just creating a
freeing the keys as you go, you just keep reusing that key structure.

bob

>

[Andrew Cagney]

On Thu, 19 Feb 2026 at 16:42, Robert Relyea <rre...@redhat.com> wrote:
>
> > The code is also churning through a lot of temp symkeys, I wonder if
> > it hits the 800 limit.
>
> The 800 is how many keys stay on the free list before NSS starts freeing
> the keys. It would take quite a feat to hit that limit. You need to
> create over 800 symkeys and then free them all to hit the limit. Doing
> 800 cycles is unlikely to hit the limit if you are just creating a
> freeing the keys as you go, you just keep reusing that key structure.

Um, yes. I realised after posting; I had it 180 out.
A growing backlog of incomplete DH negotiations (waiting on peer)
would keep the free list empty, causing new keys to be allocated. I
don't expect this to be the problem, but with max=0, I'll soon find
out.