From: Dai Ngo <dai.ngo@oracle.com>
To: Chuck Lever <chuck.lever@oracle.com>,
jlayton@kernel.org, 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:21:48 -0800 [thread overview]
Message-ID: <a180f1ba-3344-495b-b720-a4fb7058092e@oracle.com> (raw)
In-Reply-To: <9cb3fc1f-af86-4a55-8345-09dc294bcd07@oracle.com>
On 11/17/25 7:47 AM, Chuck Lever wrote:
> On 11/15/25 2:16 PM, 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) {
> The file_lock_context structure is allocated via kmem_cache_alloc() from
> flctx_cache, and it has a NULL constructor. This means newly allocated
> structures contain garbage/stale data.
>
> How are you certain that ctx->flc_conflict has been initialized (ie,
> does not contain a garbage/unknown value) ?
will fix in v5.
>
>
>> + ctx->flc_conflict = true;
>> + ctx->flc_wait_for_dispose = false;
>> + }
>>
>> 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);
> Nit: scripts/checkpatch.pl might prefer "!ctx->flc_wait_for_dispose"
> instead. Also, it wants the continuation line to align with the open
> parenthesis. Ie:
>
> wait_event_interruptible(ctx->flc_dispose_wait,
> !ctx->flc_wait_for_dispose);
will fix in v5.
>
> Notice that if ctx->flc_conflict has a garbage true value above, that
> leaves flc_wait_for_dispose unintialized as well, and this wait could
> become indefinite.
will fix in v5.
-Dai
>
>
>> + 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;
>> + wait_queue_head_t flc_dispose_wait;
>> };
>>
>> #ifdef CONFIG_FILE_LOCKING
>
next prev parent reply other threads:[~2025-11-17 19:22 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 [this message]
2025-11-17 18:21 ` Jeff Layton
2025-11-17 19:49 ` Dai Ngo
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=a180f1ba-3344-495b-b720-a4fb7058092e@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).