From: Jeff Layton <jlayton@kernel.org>
To: Dai Ngo <dai.ngo@oracle.com>,
chuck.lever@oracle.com, neilb@ownmail.net, okorniev@redhat.com,
tom@talpey.com, hch@lst.de
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/2] locks: Introduce lm_breaker_timedout op to lease_manager_operations
Date: Thu, 06 Nov 2025 12:23:13 -0500 [thread overview]
Message-ID: <8f4ce8f03919de7e29e2fc601ed9e25f392aa2c3.camel@kernel.org> (raw)
In-Reply-To: <20251106164821.300872-2-dai.ngo@oracle.com>
On Thu, 2025-11-06 at 08:47 -0800, Dai Ngo wrote:
> Some consumers of the lease_manager_operations need to perform additional
> actions when a lease break, triggered by a conflict, times out.
>
> The NFS server is the first consumer of this operation.
>
> When a pNFS layout conflict occurs, and the lease break times out -
> resulting in the layout being revoked and its file_lease beeing removed
> from the flc_lease list, the NFS server must issue a fence operation.
> This ensures that the client is prevented from accessing the data
> server after the layout is revoked.
>
> Fixes: f99d4fbdae67 ("nfsd: add SCSI layout support")
> Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
> ---
> Documentation/filesystems/locking.rst | 2 ++
> fs/locks.c | 14 +++++++++++---
> include/linux/filelock.h | 2 ++
> 3 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
> index 77704fde9845..cd600db6c4b9 100644
> --- a/Documentation/filesystems/locking.rst
> +++ b/Documentation/filesystems/locking.rst
> @@ -403,6 +403,7 @@ prototypes::
> bool (*lm_breaker_owns_lease)(struct file_lock *);
> bool (*lm_lock_expirable)(struct file_lock *);
> void (*lm_expire_lock)(void);
> + void (*lm_breaker_timedout)(struct file_lease *);
>
> locking rules:
>
> @@ -416,6 +417,7 @@ lm_change yes no no
> lm_breaker_owns_lease: yes no no
> lm_lock_expirable yes no no
> lm_expire_lock no no yes
> +lm_breaker_timedout no no yes
> ====================== ============= ================= =========
>
> buffer_head
> diff --git a/fs/locks.c b/fs/locks.c
> index 04a3f0e20724..1f254e0cd398 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -369,9 +369,15 @@ locks_dispose_list(struct list_head *dispose)
> while (!list_empty(dispose)) {
> flc = list_first_entry(dispose, struct file_lock_core, flc_list);
> list_del_init(&flc->flc_list);
> - if (flc->flc_flags & (FL_LEASE|FL_DELEG|FL_LAYOUT))
> + if (flc->flc_flags & (FL_LEASE|FL_DELEG|FL_LAYOUT)) {
> + if (flc->flc_flags & FL_BREAKER_TIMEDOUT) {
> + struct file_lease *fl = file_lease(flc);
> +
> + if (fl->fl_lmops->lm_breaker_timedout)
> + fl->fl_lmops->lm_breaker_timedout(fl);
> + }
> locks_free_lease(file_lease(flc));
> - else
> + } else
> locks_free_lock(file_lock(flc));
> }
> }
I think this would be fine in the case initial task that calls
__break_lease(), since that task will also be the one to call
locks_dispose_list() for the lease (and hence will fence the client). I
think though that if you have multiple tasks that end up blocked in
__break_lease(), that the later tasks could end up proceeding before
the client is properly fenced.
We'll need to ensure that any other breaking tasks block until the
fence operations are complete.
> @@ -1482,8 +1488,10 @@ static void time_out_leases(struct inode *inode, struct list_head *dispose)
> trace_time_out_leases(inode, fl);
> if (past_time(fl->fl_downgrade_time))
> lease_modify(fl, F_RDLCK, dispose);
> - if (past_time(fl->fl_break_time))
> + if (past_time(fl->fl_break_time)) {
> lease_modify(fl, F_UNLCK, dispose);
> + fl->c.flc_flags |= FL_BREAKER_TIMEDOUT;
> + }
> }
> }
>
> diff --git a/include/linux/filelock.h b/include/linux/filelock.h
> index c2ce8ba05d06..06ccd6b66012 100644
> --- a/include/linux/filelock.h
> +++ b/include/linux/filelock.h
> @@ -17,6 +17,7 @@
> #define FL_OFDLCK 1024 /* lock is "owned" by struct file */
> #define FL_LAYOUT 2048 /* outstanding pNFS layout */
> #define FL_RECLAIM 4096 /* reclaiming from a reboot server */
> +#define FL_BREAKER_TIMEDOUT 8192 /* lease breaker timed out */
>
> #define FL_CLOSE_POSIX (FL_POSIX | FL_CLOSE)
>
> @@ -49,6 +50,7 @@ struct lease_manager_operations {
> int (*lm_change)(struct file_lease *, int, struct list_head *);
> void (*lm_setup)(struct file_lease *, void **);
> bool (*lm_breaker_owns_lease)(struct file_lease *);
> + void (*lm_breaker_timedout)(struct file_lease *fl);
> };
>
> struct lock_manager {
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2025-11-06 17:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-06 16:47 [Patch 0/2] NFSD: Fix server hang when there are multiple layout conflicts Dai Ngo
2025-11-06 16:47 ` [PATCH 1/2] locks: Introduce lm_breaker_timedout op to lease_manager_operations Dai Ngo
2025-11-06 17:23 ` Jeff Layton [this message]
2025-11-06 20:37 ` Dai Ngo
2025-11-06 16:47 ` [PATCH 2/2] NFSD: Fix server hang when there are multiple layout conflicts Dai Ngo
2025-11-06 17:14 ` Jeff Layton
2025-11-06 17:17 ` Dai Ngo
2025-11-06 17:36 ` Jeff Layton
2025-11-06 17:50 ` Dai Ngo
-- strict thread matches above, loose matches on Subject: below --
2025-11-06 17:05 [Patch 0/2] " Dai Ngo
2025-11-06 17:05 ` [PATCH 1/2] locks: Introduce lm_breaker_timedout op to lease_manager_operations Dai Ngo
2025-11-07 13:26 ` Christoph Hellwig
2025-11-07 16:58 ` 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=8f4ce8f03919de7e29e2fc601ed9e25f392aa2c3.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=hch@lst.de \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@ownmail.net \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
/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