[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Mon, Aug 06, 2018 at 12:01:03PM +0200, Michal Prívozník wrote:
> 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).

Yep, OFD is a (nice) Linux-ism but only exists in pretty recent Linux,
and no non-Linux OS, so we can't rely on it.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]