Re: [PATCH 0/2] v3: F_OFD_GETLK extension to read lock info

[Jeff Layton]

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>