It's terribly confusing to have different functions named getLockFile and getLockfile;
rename the platform-specific one-shot one to createLockerForPath.
Also document all its surprising platform differences.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Add a method to generate a lock file for a specific digest. Such a
digest-specific lock file is needed to synchronize threads and processes
when copying blobs from a registry to the containers-storage.
Whenever a layer is about to get copied, the lock must be acquired which
indicates to other processes and threads that the layer/blob is already
being copied.
To avoid leaking file descriptors for long-living users of
containers/storage, such as CRI-O, open and close the file on demand
during Lock() and Unlock(). The internal reference counters allows to
determine if we are the first or last user.
Note: as deleting the lock files is subject to race conditions, we place
the lock files in a graph-specific directory in the runroot. Since the
runroot is a tmpfs, the files will be cleanup during reboot.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
These aren't exhaustive, but they're something.
Also change Modified() to not return an ENOSPC error when the length of
the last-writer ID doesn't match the one we'd use, since it's enough
that it's different from the one we'd use, whatever its length.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Panic in Touch() if we're not holding a write lock in one of our
threads. Hopefully that's the one we're being called from, but we
don't guarantee that.
Panic in Modified() if we're not holding some kind of lock.
As with Locked(), this doesn't keep us from getting a false positive
when it's a different thread that holds the lock, but it's better than
nothing.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Clarify that Locker.Locked() checks if we have a write lock, since
that's what we care about whenever we check it.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Enable executing parallel `GetBlob()` executions in containers/image by
using reader-lock acquisitions in `ImageBigData()` and `Diff()`.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Implement reader-writer locks to allow allow multiple readers to hold
the lock in parallel.
* The locks are still based on fcntl(2).
* Changing the lock from a reader to a writer and vice versa will block
on the syscall.
* A writer lock can be held only by one process. To protect against
concurrent accesses by gourtines within the same process space, use a
writer mutex.
* Extend the Locker interface with the `RLock()` method to acquire a
reader lock. If the lock is set to be read-only, all calls to
`Lock()` will be redirected to `RLock()`. A reader lock is only
released via fcntl(2) when all gourtines within the same process space
have unlocked it. This is done via an internal counter which is
protected (among other things) by an internal state mutex.
* Panic on violations of the lock protocol, namely when calling
`Unlock()` on an unlocked lock. This helps detecting violations in
the code but also protects the storage from corruption. Doing this
has revealed some bugs fixed in ealier commits.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
I have experienced "layer not known" corruption triggered by concurrent
buildah/skopeo processes, and hopefully lock sanity checks will help to
prevent this kind of problem.
Signed-off-by: Zac Medico <zmedico@gmail.com>
this stubs out for having platform-independent file locking
This still functions the same on `GOOS=linux`, and now succeeds for
`GOOS=windows`. But still fails on `freebsd`, `darwin`, `solaris`, etc
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Miloslav Trmač