From: "Chuck Lever" <cel@kernel.org>
To: "Jeff Layton" <jlayton@kernel.org>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Jan Kara" <jack@suse.cz>, "Chuck Lever" <chuck.lever@oracle.com>,
"Alexander Aring" <alex.aring@gmail.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
"Jonathan Corbet" <corbet@lwn.net>, NeilBrown <neil@brown.name>,
"Olga Kornievskaia" <okorniev@redhat.com>,
"Dai Ngo" <Dai.Ngo@oracle.com>, "Tom Talpey" <tom@talpey.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 0/2] filelock: fix conflict detection with userland file delegations
Date: Mon, 01 Dec 2025 11:01:38 -0500 [thread overview]
Message-ID: <d3635d5d-0594-4639-bf56-f35519b39c5b@app.fastmail.com> (raw)
In-Reply-To: <803c22e7855b699a74cf65c0ba9a0e9ad5b41257.camel@kernel.org>
On Mon, Dec 1, 2025, at 10:52 AM, Jeff Layton wrote:
> On Mon, 2025-12-01 at 10:19 -0500, Chuck Lever wrote:
>>
>> On Mon, Dec 1, 2025, at 10:08 AM, Jeff Layton wrote:
>> > This patchset fixes the way that conflicts are detected when userland
>> > requests file delegations. The problem is due to a hack that was added
>> > long ago which worked up until userland could request a file delegation.
>> >
>> > This fixes the bug and makes things a bit less hacky. Please consider
>> > for v6.19.
>>
>> I would like a little more time to review this carefully, especially
>> in light of similar work Dai has already posted in this area. If by
>> "v6.19" you mean "not before v6.19-rcN where N > 3", then that WFM.
>>
>
> Ok. Do you have a specific concern?
It looks so similar to what Dai was doing to deal with nfsd deadlocking
and my recent RFC in the same area that we should ensure that these
efforts are all going in a compatible direction.
Clearly, adding callbacks to NFSD that just return 0 is not a
functional risk ;-) But during a merge window I can't guarantee I'll
have time to look at this closely.
> FWIW, I did mention to Dai that the
> first patch in this series would make it more palatable to handle his
> new lm_breaker_timedout operation in lease_dispose_list().
>
> By v6.19, I mean before v6.19 ships. This bug needs to be fixed before
> we release a kernel that provides the new F_SETDELEG interface.
No problem. v6.19-rc rather than in the merge window is all I need.
>> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
>> > ---
>> > Jeff Layton (2):
>> > filelock: add lease_dispose_list() helper
>> > filelock: allow lease_managers to dictate what qualifies as a conflict
>> >
>> > Documentation/filesystems/locking.rst | 1 +
>> > fs/locks.c | 119 +++++++++++++++++-----------------
>> > fs/nfsd/nfs4layouts.c | 11 +++-
>> > fs/nfsd/nfs4state.c | 7 ++
>> > include/linux/filelock.h | 1 +
>> > 5 files changed, 79 insertions(+), 60 deletions(-)
>> > ---
>> > base-commit: 76c63ff12e067e1ff77b19a83c24774899ed01fc
>> > change-id: 20251201-dir-deleg-ro-41a16bc22838
>> >
>> > Best regards,
>> > --
>> > Jeff Layton <jlayton@kernel.org>
>
> --
> Jeff Layton <jlayton@kernel.org>
--
Chuck Lever
prev parent reply other threads:[~2025-12-01 16:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-01 15:08 [PATCH 0/2] filelock: fix conflict detection with userland file delegations Jeff Layton
2025-12-01 15:08 ` [PATCH 1/2] filelock: add lease_dispose_list() helper Jeff Layton
2025-12-03 18:55 ` Chuck Lever
2025-12-03 19:33 ` Jeff Layton
2025-12-03 19:35 ` Chuck Lever
2025-12-03 22:41 ` NeilBrown
2025-12-01 15:08 ` [PATCH 2/2] filelock: allow lease_managers to dictate what qualifies as a conflict Jeff Layton
2025-12-03 19:00 ` Chuck Lever
2025-12-03 19:44 ` Jeff Layton
2025-12-01 15:19 ` [PATCH 0/2] filelock: fix conflict detection with userland file delegations Chuck Lever
2025-12-01 15:52 ` Jeff Layton
2025-12-01 16:01 ` Chuck Lever [this message]
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=d3635d5d-0594-4639-bf56-f35519b39c5b@app.fastmail.com \
--to=cel@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=alex.aring@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=corbet@lwn.net \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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 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).