mirror of
https://github.com/ibm-s390-linux/s390-tools.git
synced 2026-08-05 02:14:52 +00:00
e1aec24e84
Implement simple file-locking routines that use process PIDs for stale lock detection. The implementation is meant to be a simplified subset of what liblockfile was previously being used for by libap, allowing the external dependency to be removed. This initial implementation provides a series of functions that allow for creating/release file locks using either the current process PID or the PID of the current process parent. When creating a file lock, first a temporary file is created and the appropriate PID (either this process PID or the parent process PID) is placed in the file to specify the owner of the lock. Then an attempt is made to link that file to the desired file location; if this succeeds, the lock is now held on behalf of the specified PID. If it fails, this implies the file already exists (meaning the lock is already held). In this case, stale lock detection is performed by reading the PID from the file and ensuring that the associated process still exists -- if it does not, then the lock is presumed stale and destroyed. If the process still exists, then either the lock request fails or the caller will sleep and retry, depending on an optional retry setting. A lock remains valid until either 1) it is released via the corresponding util_lockfile function, which will delete the corresponding file 2) the associated PID no longer exists, which leaves the file in-place but will cause it to be destroyed the next time a different process attempts to lock that file or 3) the file is directly removed (e.g. rm). A typical usecase for such support would be to provide a means for multiple invocations of the same (or different) tools to ensure that they do not access the same shared resource simultaneously. For example, ap-check, chzdev and lszdev all have a need to view and/or modify the AP and vfio-ap configuration files; util_lockfile can be used to ensure that only one instance of any of these utilities do that at a time by ensuring they all use the same lockfile. Additionally, providing the ability to specify the parent PID rather than the current PID allows for a general purpose tool (like mdevctl) to invoke a sub-program (ap-check) to acquire and release a lockfile as necssary while allowing stale lock detection to be controlled by that parent PID, allowing the lock to remain held over multiple sub-program invocations. Note that this implementation is sufficient for our current usage (e.g. lockfiles placed in tmpfs) but does not take into consideration things like NFS, which a more complete lockfile solution like liblockfile does. GitHub-ID: https://github.com/ibm-s390-linux/s390-tools/issues/142 Suggested-by: Luca BRUNO <luca.bruno@coreos.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Steffen Eiden <seiden@linux.ibm.com> Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
27 lines
943 B
C
27 lines
943 B
C
/**
|
|
* @defgroup util_lockfile_h util_lockfile: File locking utility
|
|
* @{
|
|
* @brief Create file-based locks
|
|
*
|
|
* Copyright IBM Corp. 2022
|
|
*
|
|
* s390-tools is free software; you can redistribute it and/or modify
|
|
* it under the terms of the MIT license. See LICENSE for details.
|
|
*/
|
|
#ifndef LIB_UTIL_LOCKFILE_H
|
|
#define LIB_UTIL_LOCKFILE_H
|
|
|
|
#define UTIL_LOCKFILE_OK 0 /* Lock acquired/released successfully */
|
|
#define UTIL_LOCKFILE_LOCK_FAIL 1 /* Lock already held, ran out of retries */
|
|
#define UTIL_LOCKFILE_RELEASE_NONE 2 /* Lock not held */
|
|
#define UTIL_LOCKFILE_RELEASE_FAIL 3 /* Lock not held by specified pid */
|
|
#define UTIL_LOCKFILE_ERR 4 /* Other, unexpected error conditions */
|
|
|
|
int util_lockfile_lock(char *lockfile, int retries);
|
|
int util_lockfile_parent_lock(char *lockfile, int retries);
|
|
|
|
int util_lockfile_release(char *lockfile);
|
|
int util_lockfile_parent_release(char *lockfile);
|
|
|
|
#endif /** LIB_UTIL_LOCKFILE_H @} */
|