Re: [libvirt] [PATCH v4 16/23] security_manager: Introduce metadata locking APIs
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