From: bfields@fieldses.org (J. Bruce Fields)
To: Jeff Layton <jlayton@kernel.org>
Cc: Chuck Lever III <chuck.lever@oracle.com>,
Trond Myklebust <trondmy@hammerspace.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH RFC] NFSD: Fix possible sleep during nfsd4_release_lockowner()
Date: Mon, 23 May 2022 16:29:38 -0400 [thread overview]
Message-ID: <20220523202938.GJ24163@fieldses.org> (raw)
In-Reply-To: <17007994486027de807d80dfde1a716c3d127de1.camel@kernel.org>
On Mon, May 23, 2022 at 03:36:27PM -0400, Jeff Layton wrote:
> The other lockowner _is_ involved. It's the one holding the conflicting
> lock. nfs4_set_lock_denied copies info from the conflicting lockowner
> into the LOCK/LOCKT response. That's safe now because it holds a
> reference to the owner. At one point it wasn't (see commit aef9583b234a4
> "NFSD: Get reference of lockowner when coping file_lock", which fixed
> that).
I doubt that commit fixed the whole problem, for what it's worth. What
if the client holding the conflicting lock expires before we get to
nfs4_set_lock_denied?
--b.
next prev parent reply other threads:[~2022-05-23 20:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-22 15:38 [PATCH RFC] NFSD: Fix possible sleep during nfsd4_release_lockowner() Chuck Lever
2022-05-23 13:40 ` Jeff Layton
2022-05-23 15:00 ` Chuck Lever III
2022-05-23 15:26 ` Jeff Layton
2022-05-23 15:41 ` Chuck Lever III
2022-05-23 16:37 ` Jeff Layton
2022-05-23 17:25 ` Chuck Lever III
2022-05-23 17:38 ` Jeff Layton
2022-05-23 19:35 ` Chuck Lever III
2022-05-23 19:43 ` Jeff Layton
2022-05-23 20:17 ` J. Bruce Fields
2022-05-23 20:32 ` Jeff Layton
2022-05-23 17:43 ` Trond Myklebust
2022-05-23 18:04 ` Jeff Layton
2022-05-23 18:21 ` Trond Myklebust
2022-05-23 18:30 ` Jeff Layton
2022-05-23 19:13 ` Chuck Lever III
2022-05-23 19:36 ` Jeff Layton
2022-05-23 20:29 ` J. Bruce Fields [this message]
2022-05-23 21:15 ` Jeff Layton
2022-05-23 21:28 ` J. Bruce Fields
2022-05-24 0:07 ` J. Bruce Fields
2022-05-23 22:18 ` Chuck Lever III
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=20220523202938.GJ24163@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.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 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.