From: Bruce Fields <bfields@fieldses.org>
To: Jonathan Woithe <jwoithe@just42.net>
Cc: Chuck Lever III <chuck.lever@oracle.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: [PATCH 2/2] lockd: fix failure to cleanup client locks
Date: Tue, 18 Jan 2022 17:00:51 -0500 [thread overview]
Message-ID: <20220118220051.GC16108@fieldses.org> (raw)
In-Reply-To: <20220118220016.GB16108@fieldses.org>
From: "J. Bruce Fields" <bfields@redhat.com>
In my testing, we're sometimes hitting the request->fl_flags & FL_EXISTS
case in posix_lock_inode, presumably just by random luck since we're not
actually initializing fl_flags here.
This probably didn't matter before 7f024fcd5c97 "Keep read and write fds
with each nlm_file" since we wouldn't previously unlock unless we knew
there were locks.
But now it causes lockd to give up on removing more locks.
We could just initialize fl_flags, but really it seems dubious to be
calling vfs_lock_file with random values in some of the fields.
Fixes: 7f024fcd5c97 ("Keep read and write fds with each nlm_file")
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
---
fs/lockd/svcsubs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
index 54c2e42130ca..0a22a2faf552 100644
--- a/fs/lockd/svcsubs.c
+++ b/fs/lockd/svcsubs.c
@@ -180,6 +180,7 @@ static int nlm_unlock_files(struct nlm_file *file)
{
struct file_lock lock;
+ locks_init_lock(&lock);
lock.fl_type = F_UNLCK;
lock.fl_start = 0;
lock.fl_end = OFFSET_MAX;
--
2.34.1
next prev parent reply other threads:[~2022-01-18 22:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 10:39 [Bug report] Recurring oops, 5.15.x, possibly during or soon after client mount Jonathan Woithe
2022-01-14 15:18 ` Chuck Lever III
2022-01-15 8:14 ` Jonathan Woithe
2022-01-15 19:46 ` Chuck Lever III
2022-01-15 21:23 ` Jonathan Woithe
2022-01-16 22:06 ` Jonathan Woithe
2022-01-16 22:30 ` Chuck Lever III
2022-01-17 7:44 ` Jonathan Woithe
2022-01-17 22:08 ` Jonathan Woithe
2022-01-17 22:11 ` Bruce Fields
2022-01-18 22:00 ` [PATCH 1/2] lockd: fix server crash on reboot of client holding lock Bruce Fields
2022-01-18 22:00 ` Bruce Fields [this message]
2022-01-18 22:20 ` Jonathan Woithe
2022-01-18 22:27 ` Bruce Fields
2022-03-23 23:33 ` Jonathan Woithe
2022-03-24 18:28 ` Bruce Fields
2022-01-19 16:18 ` Chuck Lever III
2022-01-31 22:20 ` Jonathan Woithe
2022-02-01 2:10 ` Chuck Lever III
2022-01-17 15:50 ` [Bug report] Recurring oops, 5.15.x, possibly during or soon after client mount Bruce Fields
2022-01-17 18:22 ` Chuck Lever III
2022-01-17 15:47 ` Bruce Fields
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=20220118220051.GC16108@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=jwoithe@just42.net \
--cc=linux-nfs@vger.kernel.org \
/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.