The only place where I notice a refcnt_t manipulated without a lock is in free_root_certs.
One problem is that the refcount can change between being observed and the action that is affected by the observation. Another is that the actual refcnt member isn't guaranteed to be atomic. If all operations were serialized by the mutex, this would not be a problem. The unprotected observation is a test to see if there will be any remaining references after this reference is deleted. It would be simple to change root_certs_delref() to safely return the necessary information. I've actually started to do that. But it is a little bit awkward that the existing code does not delete the reference if the count was larger than one. My simple change does delete the reference. I guess that the brute-force fix would be to add a function "refcnt_delref_if_only". It doesn't feel optimal. What's the right fix? _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev