Re: [libvirt] [RFC] secdrivers remembering original labels

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).