All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Dai Ngo <dai.ngo@oracle.com>
Cc: chuck.lever@oracle.com, jlayton@redhat.com,
	viro@zeniv.linux.org.uk, linux-nfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH RFC v12 1/3] fs/lock: add new callback, lm_lock_conflict, to lock_manager_operations
Date: Thu, 10 Feb 2022 09:28:26 -0500	[thread overview]
Message-ID: <20220210142826.GD21434@fieldses.org> (raw)
In-Reply-To: <1644468729-30383-2-git-send-email-dai.ngo@oracle.com>

On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index bbf812ce89a8..726d0005e32f 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1068,6 +1068,14 @@ struct lock_manager_operations {
>  	int (*lm_change)(struct file_lock *, int, struct list_head *);
>  	void (*lm_setup)(struct file_lock *, void **);
>  	bool (*lm_breaker_owns_lease)(struct file_lock *);
> +	/*
> +	 * This callback function is called after a lock conflict is
> +	 * detected. This allows the lock manager of the lock that
> +	 * causes the conflict to see if the conflict can be resolved
> +	 * somehow. If it can then this callback returns false; the
> +	 * conflict was resolved, else returns true.
> +	 */
> +	bool (*lm_lock_conflict)(struct file_lock *cfl);
>  };

I don't love that name.  The function isn't checking for a lock
conflict--it'd have to know *what* the lock is conflicting with.  It's
being told whether the lock is still valid.

I'd prefer lm_lock_expired(), with the opposite return values.

(Apologies if this has already been woodshedded to death, I haven't been
following.)

--b.

  parent reply	other threads:[~2022-02-10 14:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10  4:52 [PATCH RFC v12 0/3] nfsd: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-02-10  4:52 ` [PATCH RFC v12 1/3] fs/lock: add new callback, lm_lock_conflict, to lock_manager_operations Dai Ngo
2022-02-10 14:21   ` J. Bruce Fields
2022-02-10 14:29     ` Jeff Layton
2022-02-10 19:41       ` dai.ngo
2022-02-10 19:44         ` Chuck Lever III
2022-02-10 19:56           ` dai.ngo
2022-02-10 14:28   ` J. Bruce Fields [this message]
2022-02-10 16:50     ` Chuck Lever III
2022-02-10 17:32       ` Jeff Layton
2022-02-10 19:47     ` dai.ngo
2022-02-10  4:52 ` [PATCH RFC v12 2/3] fs/lock: only call lm_breaker_owns_lease if there is conflict Dai Ngo
2022-02-10  4:52 ` [PATCH RFC v12 3/3] nfsd: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-02-10 15:17   ` J. Bruce Fields
2022-02-10 16:32     ` J. Bruce Fields
2022-02-10 16:52       ` Chuck Lever III
2022-02-10 18:59         ` Bruce Fields
2022-02-10 19:04           ` Chuck Lever III
2022-02-10 19:52     ` dai.ngo

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=20220210142826.GD21434@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=dai.ngo@oracle.com \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.