On Fri, Aug 24, 2018 at 03:29:24PM +0200, Michal Privoznik wrote:
On 08/24/2018 02:53 PM, Daniel P. Berrangé wrote:
That sounds reasonable, so we don't need the _WAIT behaviour in virtlockd itself, as everything will wait in the secdriver instead. At least for now, until we modularize the startup process with the shim. Guess that's just one more todo item to solve for the shim so not the end of the world.
Hold on, we do need _WAIT so that we mutually exclude other virtlockd-s from other hosts fiddling with seclabels on a shared NFS. However, we will not deadlock on a single host, that's what I'm saying.
Right but later when multiple clients are permitted to connect to the same virtlockd, the API they will use has a designed in deadlock :-( 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 :|