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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
