On 09/18/2018 12:12 AM, John Ferlan wrote:
[...]
+
After seeing it in use in patch 19 and thinking about it for a very short period of time, would it make more sense to store @lock somewhere so that virSecurityManagerMetadataUnlock doesn't fail because the virSecurityManagerNewLockManager fails?
The @mgr is mutex locked so that nothing can change @mgr while this Meta Lock/Unlock is occurring. It'd be a shame to not call virLockManagerRelease just because we didn't save @lock
I will look into this, but quick glance over virSecurityManagerNewLockManager() tells me that it can fail only in OOM case (which means you're in much bigger trouble anyway). (some time passes) So I did take a look and we would need to save both FD and @lock. However, saving those two would not save us from allocating memory. Even then the virLockManagerLockDaemonRelease() allocates memory (for client, connection, etc.). Long story short, I don't think it is worth the effort. Michal