From: Dai Ngo <dai.ngo@oracle.com>
To: Jeff Layton <jlayton@kernel.org>,
chuck.lever@oracle.com, neilb@ownmail.net, okorniev@redhat.com,
tom@talpey.com, hch@lst.de, alex.aring@gmail.com,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz
Cc: linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v4 2/3] locks: Threads with layout conflict must wait until client was fenced.
Date: Mon, 17 Nov 2025 11:49:39 -0800 [thread overview]
Message-ID: <0c8e2b9a-0db1-4a3d-a15f-7f5b0ed12d51@oracle.com> (raw)
In-Reply-To: <5d19304ea493177c35d0ce13abe6dbf358240fa1.camel@kernel.org>
On 11/17/25 10:21 AM, Jeff Layton wrote:
> On Sat, 2025-11-15 at 11:16 -0800, Dai Ngo wrote:
>> If multiple threads are waiting for a layout conflict on the same
>> file in __break_lease, these threads must wait until one of the
>> waiting threads completes the fencing operation before proceeding.
>> This ensures that I/O operations from these threads can only occurs
>> after the client was fenced.
>>
>> Fixes: f99d4fbdae67 ("nfsd: add SCSI layout support")
>> Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
>> ---
>> fs/locks.c | 24 ++++++++++++++++++++++++
>> include/linux/filelock.h | 5 +++++
>> 2 files changed, 29 insertions(+)
>>
>> diff --git a/fs/locks.c b/fs/locks.c
>> index 1f254e0cd398..b6fd6aa2498c 100644
>> --- a/fs/locks.c
>> +++ b/fs/locks.c
>> @@ -191,6 +191,7 @@ locks_get_lock_context(struct inode *inode, int type)
>> INIT_LIST_HEAD(&ctx->flc_flock);
>> INIT_LIST_HEAD(&ctx->flc_posix);
>> INIT_LIST_HEAD(&ctx->flc_lease);
>> + init_waitqueue_head(&ctx->flc_dispose_wait);
>>
>> /*
>> * Assign the pointer if it's not already assigned. If it is, then
>> @@ -1609,6 +1610,10 @@ int __break_lease(struct inode *inode, unsigned int mode, unsigned int type)
>> error = -EWOULDBLOCK;
>> goto out;
>> }
>> + if (type == FL_LAYOUT && !ctx->flc_conflict) {
>> + ctx->flc_conflict = true;
>> + ctx->flc_wait_for_dispose = false;
>> + }
> I don't like special casing this for FL_LAYOUT leases. It seems like we
> ought to be able to set up a lm_breaker_timedout operation on any sort
> of lease.
I just try to minimize the effect of the change to FL_LAYOUT, but if
you think that is not necessary then I will remove the case in v5.
>
>>
>> restart:
>> fl = list_first_entry(&ctx->flc_lease, struct file_lease, c.flc_list);
>> @@ -1640,12 +1645,31 @@ int __break_lease(struct inode *inode, unsigned int mode, unsigned int type)
>> time_out_leases(inode, &dispose);
>> if (any_leases_conflict(inode, new_fl))
>> goto restart;
>> + if (type == FL_LAYOUT && ctx->flc_wait_for_dispose) {
>> + /*
>> + * wait for flc_wait_for_dispose to ensure
>> + * the offending client has been fenced.
>> + */
>> + spin_unlock(&ctx->flc_lock);
>> + wait_event_interruptible(ctx->flc_dispose_wait,
>> + ctx->flc_wait_for_dispose == false);
>> + spin_lock(&ctx->flc_lock);
>> + }
>> error = 0;
>> + if (type == FL_LAYOUT)
>> + ctx->flc_wait_for_dispose = true;
>> }
>> out:
>> spin_unlock(&ctx->flc_lock);
>> percpu_up_read(&file_rwsem);
>> locks_dispose_list(&dispose);
>> + if (type == FL_LAYOUT) {
>> + spin_lock(&ctx->flc_lock);
>> + ctx->flc_wait_for_dispose = false;
>> + ctx->flc_conflict = false;
>> + wake_up(&ctx->flc_dispose_wait);
>> + spin_unlock(&ctx->flc_lock);
>> + }
>> free_lock:
>> locks_free_lease(new_fl);
>> return error;
>> diff --git a/include/linux/filelock.h b/include/linux/filelock.h
>> index 06ccd6b66012..5c5353aabbc8 100644
>> --- a/include/linux/filelock.h
>> +++ b/include/linux/filelock.h
>> @@ -146,6 +146,11 @@ struct file_lock_context {
>> struct list_head flc_flock;
>> struct list_head flc_posix;
>> struct list_head flc_lease;
>> +
>> + /* for FL_LAYOUT */
>> + bool flc_conflict;
>> + bool flc_wait_for_dispose;
> I'm also not a fan of this particular bool. Waiting for any
> lm_breaker_timeout operations to complete seems like something we ought
> to just always do. In the trivial case where we have no special fencing
> to do, that should just return quickly anyway.
I have to think more about this. Without the flc_wait_for_dispose flag,
I don't have a way to allow one thread to proceed to do the fencing
while the rest have to wait until the fencing is done. Do you have any
suggestion?
-Dai
>
>> + wait_queue_head_t flc_dispose_wait;
>> };
>>
>> #ifdef CONFIG_FILE_LOCKING
next prev parent reply other threads:[~2025-11-17 19:50 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-15 19:16 [Patch v4 0/3] NFSD: Fix server hang when there are multiple layout conflicts Dai Ngo
2025-11-15 19:16 ` [PATCH v4 1/3] locks: Introduce lm_breaker_timedout operation to lease_manager_operations Dai Ngo
2025-11-17 15:39 ` Chuck Lever
2025-11-17 19:17 ` Dai Ngo
2025-11-17 18:02 ` Jeff Layton
2025-11-17 19:41 ` Dai Ngo
2025-11-19 13:52 ` Jeff Layton
2025-11-19 16:32 ` Dai Ngo
2025-11-19 9:54 ` Christoph Hellwig
2025-11-19 14:04 ` Chuck Lever
2025-11-15 19:16 ` [PATCH v4 2/3] locks: Threads with layout conflict must wait until client was fenced Dai Ngo
2025-11-17 15:47 ` Chuck Lever
2025-11-17 19:21 ` Dai Ngo
2025-11-17 18:21 ` Jeff Layton
2025-11-17 19:49 ` Dai Ngo [this message]
2025-11-19 9:53 ` Christoph Hellwig
2025-11-15 19:16 ` [PATCH v4 3/3] FSD: Fix NFS server hang when there are multiple layout conflicts Dai Ngo
2025-11-15 19:44 ` Chuck Lever
2025-11-15 20:20 ` Dai Ngo
2025-11-19 9:56 ` Christoph Hellwig
2025-11-19 16:35 ` Dai Ngo
2025-11-17 15:55 ` Chuck Lever
2025-11-17 19:40 ` Dai Ngo
2025-11-17 21:13 ` Benjamin Coddington
2025-11-17 22:00 ` Dai Ngo
2025-11-19 10:08 ` Christoph Hellwig
2025-11-19 16:52 ` Dai Ngo
2025-11-20 6:50 ` Christoph Hellwig
2025-11-19 10:05 ` Christoph Hellwig
2025-11-19 14:04 ` Benjamin Coddington
2025-11-19 14:09 ` Chuck Lever
2025-11-19 14:12 ` Jeff Layton
2025-11-19 17:06 ` Dai Ngo
2025-11-20 6:52 ` Christoph Hellwig
2025-11-20 6:59 ` Christoph Hellwig
2025-11-19 9:57 ` Christoph Hellwig
2025-11-19 10:08 ` Christoph Hellwig
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=0c8e2b9a-0db1-4a3d-a15f-7f5b0ed12d51@oracle.com \
--to=dai.ngo@oracle.com \
--cc=alex.aring@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@ownmail.net \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
--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).