On Mon, 11 Feb 2002, Paul Dokas wrote:

> On Mon, Jan 14, 2002 at 09:39:52PM +0100, Urban Boquist wrote:
> Also, all of the stack traces that I've seen seem to revolve around key_freesp()
> and/or they seem to indicate that the memory has already been freed.
>
> I haven't tested a fix yet, but I suspect that it might be as simple as not
> calling key_freesp() from ipsec_fillpcbcache(), ipsec_invalpcbcache() or any
> of the other places that it's called from.  See the patches mentioned in
> kern/13813.
>
>
> Could someone more familiar with this section of code please take a look and
> see if I'm anywhere near right on this?

I haven't looked at the code, but what you describe sounds like a problem.

Another solution is, do the freers check to see if the value is NULL
before freeing? If so, have the pointer set to NULL after it is freed.
Then it gets freed only once.

I suggest this as I don't know the call graph - could some of these
potential free points be called when others aren't? If so, then they need
to all be able to free. By setting the pointer to NULL (and checking !=
NULL), any one of them will free it only once.

Take care,

Bill