[libvirt] [RFC] secdrivers remembering original labels
Michal Prívozník
mprivozn at redhat.com
Mon Aug 6 10:01:03 UTC 2018
On 08/06/2018 10:30 AM, Daniel P. Berrangé wrote:
>>
>> So do we really need virtlockd for this? I mean, the whole purpose of it
>> is to hold locks so that libvirtd can restart independently, without
>> losing the lock attached. However, since the metadata lock will be held
>> only for a fraction of a second and will be not held through more than a
>> single API aren't we just fine with libvirtd holding the lock? The way I
>> imagine this to work is the following:
>
> There were two reasons for virtlockd. The first was the persistent holding
> of locks, but the other reasons is that POSIX fcntl() locks are horrific.
> If one thread has an FD open with a lock held, if another thread opens and
> closes the same underlying file, the first thread's lock will get dropped.
>
> We can't be confident that other threads won't open the file, so the only
> way to be safe was to put locking in to a separate process where we know
> exactly what all threads are doing.
Ah. That's terrible. But IIUC avoidable by using OFDs instead (which are
not available on BSD I presume).
>
>
>> Frankly, I've started implementing this with virtlockd already, but the
>> changes I made so far simply do not feel right, e.g. I have to change
>> lock_protocol.x so that virLockSpaceProtocolAcquireResourceArgs has this
>> 'type' argument which tells virtlockd which byte we want to lock.
>
> We could perhaps make use of the "flags" field, giving a flg to identify
> the lockspace to use. This could be turned into an offset server side.
Okay, I'll try this. Thanks!
Michal
More information about the libvir-list
mailing list