On 08/23/2018 05:51 PM, Daniel P. Berrangé wrote:
On Thu, Aug 23, 2018 at 05:45:42PM +0200, Michal Privoznik wrote:
On 08/23/2018 05:01 PM, Daniel P. Berrangé wrote:
On Thu, Aug 23, 2018 at 04:54:01PM +0200, Michal Privoznik wrote:
On 08/20/2018 07:17 PM, Michal Prívozník wrote:
On 08/20/2018 05:16 PM, Daniel P. Berrangé wrote:
On Tue, Aug 14, 2018 at 01:19:43PM +0200, Michal Privoznik wrote: > Fortunately, we have qemu wrappers so it's sufficient to put > lock/unlock call only there. > > Signed-off-by: Michal Privoznik <mprivozn@redhat.com> > --- > src/qemu/qemu_security.c | 107 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 107 insertions(+) >
Oh right, yes, that kills the idea of using a WAIT flag for lockspaces, unless we want to introduce threads ingto virtlockd, but we can't do that because Linux has totally fubard locking across execve() :-(
But we need WAIT. I guess we do not want to do: lockForMetadata(const char *path) { int retries; while (retries) { rc = try_lock(path, wait=false); if (!rc) break; if (errno = EAGAIN && retries--) {sleep(.1); continue;} errorOut(); } } However, if we make sure that virtlockd never forks() nor execs() we have nothing to fear about. Or am I missing something? And to be 100% sure we can always provide dummy impl for fork() + execve() in src/locking/lock_daemon.c which fails everytime. Michal