On Thu, 2023-06-22 at 21:52 +0500, Stas Sergeev wrote: > This extension allows to use F_UNLCK on query, which currently returns > EINVAL. Instead it can be used to query the locks on a particular fd - > something that is not currently possible. The basic idea is that on > F_OFD_GETLK, F_UNLCK would "conflict" with (or query) any types of the > lock on the same fd, and ignore any locks on other fds. > > Use-cases: > > 1. CRIU-alike scenario when you want to read the locking info from an > fd for the later reconstruction. This can now be done by setting > l_start and l_len to 0 to cover entire file range, and do F_OFD_GETLK. > In the loop you need to advance l_start past the returned lock ranges, > to eventually collect all locked ranges. > > 2. Implementing the lock checking/enforcing policy. > Say you want to implement an "auditor" module in your program, > that checks that the I/O is done only after the proper locking is > applied on a file region. In this case you need to know if the > particular region is locked on that fd, and if so - with what type > of the lock. If you would do that currently (without this extension) > then you can only check for the write locks, and for that you need to > probe the lock on your fd and then open the same file via another fd and > probe there. That way you can identify the write lock on a particular > fd, but such trick is non-atomic and complex. As for finding out the > read lock on a particular fd - impossible. > This extension allows to do such queries without any extra efforts. > > 3. Implementing the mandatory locking policy. > Suppose you want to make a policy where the write lock inhibits any > unlocked readers and writers. Currently you need to check if the > write lock is present on some other fd, and if it is not there - allow > the I/O operation. But because the write lock can appear at any moment, > you need to do that under some global lock, which can be released only > when the I/O operation is finished. > With the proposed extension you can instead just check the write lock > on your own fd first, and if it is there - allow the I/O operation on > that fd without using any global lock. Only if there is no write lock > on this fd, then you need to take global lock and check for a write > lock on other fds. > > > The second patch adds a test-case for OFD locks. > It tests both the generic things and the proposed extension. > > > The third patch is a proposed man page update for fcntl(2) > (not for the linux source tree) > > > Changes in v3: > - Move selftest to selftests/filelock > > Changes in v2: > - Dropped the l_pid extension patch and updated test-case accordingly. > > Stas Sergeev (2): > fs/locks: F_UNLCK extension for F_OFD_GETLK > selftests: add OFD lock tests > > fs/locks.c | 23 +++- > tools/testing/selftests/filelock/Makefile | 5 + > tools/testing/selftests/filelock/ofdlocks.c | 132 ++++++++++++++++++++ > 3 files changed, 157 insertions(+), 3 deletions(-) > create mode 100644 tools/testing/selftests/filelock/Makefile > create mode 100644 tools/testing/selftests/filelock/ofdlocks.c > > CC: Jeff Layton <jlayton@xxxxxxxxxx> > CC: Chuck Lever <chuck.lever@xxxxxxxxxx> > CC: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx> > CC: Christian Brauner <brauner@xxxxxxxxxx> > CC: linux-fsdevel@xxxxxxxxxxxxxxx > CC: linux-kernel@xxxxxxxxxxxxxxx > CC: Shuah Khan <shuah@xxxxxxxxxx> > CC: linux-kselftest@xxxxxxxxxxxxxxx > CC: linux-api@xxxxxxxxxxxxxxx > I've taken the first two patches into my locks-next branch, so they should end up in linux-next soon. Adding support for testing this to fstests is a hard requirement before this will be merged into mainline. Thanks, -- Jeff Layton <jlayton@xxxxxxxxxx>
