A flock lock descriptor opened with a raw syscall.Open and no O_CLOEXEC is inherited across exec by every child the holder starts, so a child that outlives its dead parent keeps the lock held: the next writer gets contention after its whole budget, although the process that took the lock is gone. Shown by a re-exec test: a WithFileLock holder that starts a sleep and is killed leaves the lock ungrantable for 2s while the sleep lives. The descriptors affected are fsutil.WithFileLock's openLockFd, memory's store lock (writer.go) and the directory locks of decide, intent and spec; os.OpenFile and os.Root add O_CLOEXEC themselves, so WithFileLockIn and history's repoLock are not affected.

A flock lock descriptor opened with a raw syscall.Open and no O_CLOEXEC is inherited across exec by every child the holder starts, so a child that outlives its dead parent keeps the lock held: the next writer gets contention after its whole budget, although the process that took the lock is gone. Shown by a re-exec test: a WithFileLock holder that starts a sleep and is killed leaves the lock ungrantable for 2s while the sleep lives. The descriptors affected are fsutil.WithFileLock's openLockFd, memory's store lock (writer.go) and the directory locks of decide, intent and spec; os.OpenFile and os.Root add O_CLOEXEC themselves, so WithFileLockIn and history's repoLock are not affected.

Grounds

• pursued: we expect no lock to outlive the process that took it through a child it started; a re-exec test whose killed holder's grandchild still keeps the lock (contention past the budget) would show it wrong