[libvirt] [PATCH v4 00/23] Introduce metadata locking

[Michal Privoznik]

On 09/12/2018 07:19 AM, Bjoern Walk wrote:
> Michal Privoznik <mprivozn at redhat.com> [2018-09-10, 11:36AM +0200]:
>> Technically, this is v4 of:
>>
>> https://www.redhat.com/archives/libvir-list/2018-August/msg01627.html
>>
>> However, this is implementing different approach than any of the
>> previous versions.
>>
>> One of the problems with previous version was that it was too
>> complicated. The main reason for that was that we could not close the
>> connection whilst there was a file locked. So we had to invent a
>> mechanism that would prevent that (on the client side).
>>
>> These patches implement different approach. They rely on secdriver's
>> transactions which bring all the paths we want to label into one place
>> so that they can be relabelled within different namespace.
>> I'm extending this idea so that transactions run all the time
>> (regardless of domain namespacing) and only at the very last moment is
>> decided which namespace would the relabeling run in.
>>
>> Metadata locking is then as easy as putting lock/unlock calls around one
>> function.
>>
>> You can find the patches at my github too:
>>
>> https://github.com/zippy2/libvirt/tree/disk_metadata_lock_v4_alt
> 
> Hey Michal,
> 
> is was running a quick test with this patch series with two domains
> sharing a disk image without <shareable/> and SELinux enabled. When
> starting the second domain, the whole libvirtd daemon hangs for almost a
> minute until giving the error that the image is locked. I haven't
> debugged it yet to figure out what happens.

Is this on two different hosts or one?

I'm unable to reproduce, so can you please attach debugger and share 't
a a bt' output with me?

When I try to reproduce I always get one domain running and the other
failing to start because qemu is unable to do its locking. When I put
<shareable/> in both, they start successfully.

TBH, I don't run SELinux enabled host so I'm testing DAC only, but the
changes to the code are merely the same. So I'm wondering if this is
really an issue in my SELinux impl or somewhere else.

BTW: The one minute timeout comes from patch 16/23:

  #define LOCK_ACQUIRE_TIMEOUT 60

Michal