On Fri, Mar 02, 2018 at 03:24:53PM -0700, Jim Fehlig wrote:
On 03/02/2018 11:12 AM, Daniel P. Berrangé wrote:
On Fri, Mar 02, 2018 at 04:52:23PM +0000, Daniel P. Berrangé wrote:
On Thu, Mar 01, 2018 at 04:42:36PM -0700, Jim Fehlig wrote:
Locks held by virtlockd are dropped on re-exec.
virtlockd 94306 POSIX 5.4G WRITE 0 0 0 /tmp/test.qcow2 virtlockd 94306 POSIX 5B WRITE 0 0 0 /run/virtlockd.pid virtlockd 94306 POSIX 5B WRITE 0 0 0 /run/virtlockd.pid
Acquire locks in PostExecRestart code path.
This is really strange and should *not* be happening. POSIX locks are supposed to be preserved across execve() if the FD has CLOEXEC unset, and you don't fork() before the exec.
[snip]
So I wonder what we've screwed up to cause the locks to get released - reaquiring them definitely isn't desirable as we should not loose them in the first place !
This is really very strange. The problem seems to be the existance of threads at time of execve().
If you spawn a thread and the thread exits, and you execve the locks are preserved.
If you spawn a thread and the thread is still running, and you execve the locks are lost.
Indeed you are correct. I'm seeing the same behavior with the below modifications to your demo. The lock is preserved after execve when BREAK_FLOCK is 0, but removed when BREAK_FLOCK is 1.
I tried RHEL7 vintage kernel and saw the same behaviour, so this seems to be a fairly long standing issue. In theory we can make virNetServer single-threaded by passing max_workers==0 when creating it, but I just tried that and hit deadlock, so it seems that code has bit-rotted. If I we can fix that, then I think leaving it single threaded is the easiest way to deal with this. Failing that, we would have to arrange to cleanly terminate all threads before re-exec'ing. 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 :|