linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Stas Sergeev <stsp2@yandex.ru>, linux-kernel@vger.kernel.org
Cc: Chuck Lever <chuck.lever@oracle.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/3] fs/locks: F_UNLCK extension for F_OFD_GETLK
Date: Tue, 20 Jun 2023 06:46:50 -0400	[thread overview]
Message-ID: <c6d4e620cad72da5f85df03443a64747b5719939.camel@kernel.org> (raw)
In-Reply-To: <20230620095507.2677463-2-stsp2@yandex.ru>

On Tue, 2023-06-20 at 14:55 +0500, Stas Sergeev wrote:
> Currently F_UNLCK with F_OFD_GETLK returns -EINVAL.
> The proposed extension allows to use it for getting the lock
> information from the particular fd.
> 
> Signed-off-by: Stas Sergeev <stsp2@yandex.ru>
> 
> CC: Jeff Layton <jlayton@kernel.org>
> CC: Chuck Lever <chuck.lever@oracle.com>
> CC: Alexander Viro <viro@zeniv.linux.org.uk>
> CC: Christian Brauner <brauner@kernel.org>
> CC: linux-fsdevel@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> 
> ---
>  fs/locks.c | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index df8b26a42524..210766007e63 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -868,6 +868,21 @@ static bool posix_locks_conflict(struct file_lock *caller_fl,
>  	return locks_conflict(caller_fl, sys_fl);
>  }
>  
> +/* Determine if lock sys_fl blocks lock caller_fl. Used on xx_GETLK
> + * path so checks for additional GETLK-specific things like F_UNLCK.
> + */
> +static bool posix_test_locks_conflict(struct file_lock *caller_fl,
> +				      struct file_lock *sys_fl)
> +{
> +	/* F_UNLCK checks any locks on the same fd. */
> +	if (caller_fl->fl_type == F_UNLCK) {
> +		if (!posix_same_owner(caller_fl, sys_fl))
> +			return false;
> +		return locks_overlap(caller_fl, sys_fl);
> +	}
> +	return posix_locks_conflict(caller_fl, sys_fl);
> +}
> +
>  /* Determine if lock sys_fl blocks lock caller_fl. FLOCK specific
>   * checking before calling the locks_conflict().
>   */
> @@ -901,7 +916,7 @@ posix_test_lock(struct file *filp, struct file_lock *fl)
>  retry:
>  	spin_lock(&ctx->flc_lock);
>  	list_for_each_entry(cfl, &ctx->flc_posix, fl_list) {
> -		if (!posix_locks_conflict(fl, cfl))
> +		if (!posix_test_locks_conflict(fl, cfl))
>  			continue;
>  		if (cfl->fl_lmops && cfl->fl_lmops->lm_lock_expirable
>  			&& (*cfl->fl_lmops->lm_lock_expirable)(cfl)) {
> @@ -2207,7 +2222,8 @@ int fcntl_getlk(struct file *filp, unsigned int cmd, struct flock *flock)
>  	if (fl == NULL)
>  		return -ENOMEM;
>  	error = -EINVAL;
> -	if (flock->l_type != F_RDLCK && flock->l_type != F_WRLCK)
> +	if (cmd != F_OFD_GETLK && flock->l_type != F_RDLCK
> +			&& flock->l_type != F_WRLCK)
>  		goto out;
>  
>  	error = flock_to_posix_lock(filp, fl, flock);
> @@ -2414,7 +2430,8 @@ int fcntl_getlk64(struct file *filp, unsigned int cmd, struct flock64 *flock)
>  		return -ENOMEM;
>  
>  	error = -EINVAL;
> -	if (flock->l_type != F_RDLCK && flock->l_type != F_WRLCK)
> +	if (cmd != F_OFD_GETLK && flock->l_type != F_RDLCK
> +			&& flock->l_type != F_WRLCK)
>  		goto out;
>  
>  	error = flock64_to_posix_lock(filp, fl, flock);

This seems like a reasonable sort of interface to add, particularly for
the CRIU case. Using F_UNLCK for this is a bit kludgey, but adding a new
constant is probably worse.

I'm willing to take this in with an eye toward v6.6. Are you also
willing to draft up some manpage patches that detail this new interface?

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2023-06-20 10:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20  9:55 [PATCH 0/3] RFC: F_OFD_GETLK should provide more info Stas Sergeev
2023-06-20  9:55 ` [PATCH 1/3] fs/locks: F_UNLCK extension for F_OFD_GETLK Stas Sergeev
2023-06-20 10:46   ` Jeff Layton [this message]
2023-06-20 11:00     ` stsp
2023-06-20 11:15       ` Jeff Layton
2023-06-21 15:24         ` stsp
2023-06-20  9:55 ` [PATCH 2/3] fd/locks: allow get the lock owner by F_OFD_GETLK Stas Sergeev
2023-06-20 10:51   ` Jeff Layton
2023-06-20 10:57     ` stsp
2023-06-20 11:12       ` Jeff Layton
2023-06-20 11:45         ` stsp
2023-06-20 12:02           ` Jeff Layton
2023-06-20 12:34             ` stsp
2023-06-20 13:19               ` Jeff Layton
2023-06-20 13:39                 ` stsp
2023-06-20 13:46                   ` Matthew Wilcox
2023-06-20 13:47                     ` stsp
2023-06-20 14:36                       ` Matthew Wilcox
2023-06-20 15:45                         ` stsp
2023-06-20 17:05                           ` Matthew Wilcox
2023-06-21  2:54                             ` stsp
2023-06-23 13:10                     ` David Laight
2023-06-20 13:58                   ` Jeff Layton
2023-06-21  6:57                     ` stsp
2023-06-21 10:35                       ` Jeff Layton
2023-06-21 10:42                         ` stsp
2023-06-21 11:05                           ` Jeff Layton
2023-06-21 11:22                             ` stsp
2023-06-21 11:26                               ` stsp
2023-06-23 15:25                             ` Christian Brauner
2023-06-23 17:18                               ` stsp
2023-06-27 16:00                                 ` Jeff Layton
2023-06-27 16:20                                   ` stsp
2023-06-20  9:55 ` [PATCH 3/3] selftests: add OFD lock tests Stas Sergeev
2023-06-20 11:06   ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6d4e620cad72da5f85df03443a64747b5719939.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stsp2@yandex.ru \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).