[libvirt] [PATCH v4 08/23] lock_driver: Introduce new VIR_LOCK_MANAGER_OBJECT_TYPE_DAEMON

[Michal Privoznik]

On 09/17/2018 06:17 PM, John Ferlan wrote:
> 
> 
> On 09/10/2018 05:36 AM, Michal Privoznik wrote:
>> We will want virtlockd to lock files on behalf of libvirtd and
>> not qemu process, because it is libvirtd that needs an exclusive
>> access not qemu. This requires new lock context.
>>
>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>> ---
>>  src/locking/lock_driver.h         |   2 +
>>  src/locking/lock_driver_lockd.c   | 291 ++++++++++++++++++++++++--------------
>>  src/locking/lock_driver_sanlock.c |  37 +++--
>>  3 files changed, 214 insertions(+), 116 deletions(-)
>>
> 
> [...]
> 
>> @@ -156,10 +167,24 @@ virLockManagerLockDaemonConnectionRegister(virLockManagerPtr lock,
>>      memset(&args, 0, sizeof(args));
>>  
>>      args.flags = 0;
>> -    memcpy(args.owner.uuid, priv->uuid, VIR_UUID_BUFLEN);
>> -    args.owner.name = priv->name;
>> -    args.owner.id = priv->id;
>> -    args.owner.pid = priv->pid;
>> +
>> +    switch (priv->type) {
>> +    case VIR_LOCK_MANAGER_OBJECT_TYPE_DOMAIN:
>> +        memcpy(args.owner.uuid, priv->t.dom.uuid, VIR_UUID_BUFLEN);
>> +        args.owner.name = priv->t.dom.name;
>> +        args.owner.id = priv->t.dom.id;
>> +        args.owner.pid = priv->t.dom.pid;
>> +        break;
>> +
>> +    case VIR_LOCK_MANAGER_OBJECT_TYPE_DAEMON:
>> +        memcpy(args.owner.uuid, priv->t.daemon.uuid, VIR_UUID_BUFLEN);
>> +        args.owner.name = priv->t.daemon.name;
>> +        args.owner.pid = priv->t.daemon.pid;
>> +        break;
>> +
>> +    default:
> 
> Should there be an error message? Since virNetClientProgramCall would
> provide one on error and it seems callers would expect it... So we don't
> end up with an error happened, but we have no clue where.

The 'default' label exists merely to shut gcc up. However, I'll copy the
error message from virLockManagerLockDaemonNew().

> 
>> +        return -1;
>> +    }
>>  
>>      if (virNetClientProgramCall(program,
>>                                  client,
> 
> [...]
> 
> I suspect you can make the right choice above...
> 
> Reviewed-by: John Ferlan <jferlan at redhat.com>

Michal