Re: IPFilter issue in -current

[David Laight <david%l8s.co.uk@localhost>]

On Sun, Dec 23, 2012 at 06:05:34PM +1100, Darren Reed wrote:
> ok, now that I've studied the patches...
> 
> The change to ip_nat.c (adding a MUTEX_DESTROY()) is a no-op.
> 
> The reason for this is that when ipf_nat_insert() fails (as is
> with the case for which you are adding code), it is assumed that
> the "nat" pointer can be free'd without any further action. So
> calling MUTEX_DESTROY() there serves no purpose as nothing is
> going to touch that lock again.

I had a feeling that, on some OS at least (Solaris?), a mutex
contained a pointer to dynamically allocated memeory making it
necessary to actually 'destroy' it?

        David

-- 
David Laight: david%l8s.co.uk@localhost