From: Christoph Hellwig <hch@lst.de>
To: Dai Ngo <dai.ngo@oracle.com>
Cc: chuck.lever@oracle.com, jlayton@kernel.org, neil@brown.name,
okorniev@redhat.com, tom@talpey.com, hch@lst.de,
alex.aring@gmail.com, linux-fsdevel@vger.kernel.org,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/1] NFSD: Enforce recall timeout for layout conflict
Date: Tue, 20 Jan 2026 08:26:38 +0100 [thread overview]
Message-ID: <20260120072638.GA6380@lst.de> (raw)
In-Reply-To: <20260119174737.3619599-1-dai.ngo@oracle.com>
On Mon, Jan 19, 2026 at 09:47:24AM -0800, Dai Ngo wrote:
> When a layout conflict triggers a recall, enforcing a timeout
> is necessary to prevent excessive nfsd threads from being tied
> up in __break_lease and ensure the server can continue servicing
> incoming requests efficiently.
>
> This patch introduces two new functions in lease_manager_operations:
>
> 1. lm_breaker_timedout: Invoked when a lease recall times out,
> allowing the lease manager to take appropriate action.
>
> The NFSD lease manager uses this to handle layout recall
> timeouts. If the layout type supports fencing, a fence
> operation is issued to prevent the client from accessing
> the block device.
>
> 2. lm_need_to_retry: Invoked when there is a lease conflict.
> This allows the lease manager to instruct __break_lease
> to return an error to the caller, prompting a retry of
> the conflicting operation.
>
> The NFSD lease manager uses this to avoid excessive nfsd
> from being blocked in __break_lease, which could hinder
> the server's ability to service incoming requests.
>
> Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
This looks reasonable to me, but I don't really feel confident
enough about the locks.c code that you should consider this a
review.
next prev parent reply other threads:[~2026-01-20 7:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 17:47 [PATCH 1/1] NFSD: Enforce recall timeout for layout conflict Dai Ngo
2026-01-19 22:49 ` kernel test robot
2026-01-20 7:26 ` Christoph Hellwig [this message]
2026-01-20 18:54 ` Dai Ngo
2026-01-21 8:38 ` Christoph Hellwig
2026-01-20 15:19 ` Chuck Lever
2026-01-20 19:22 ` Dai Ngo
2026-01-20 20:55 ` Dai Ngo
2026-01-20 20:41 ` Jeff Layton
2026-01-20 21:22 ` Dai Ngo
2026-01-20 21:28 ` Jeff Layton
2026-01-20 21:42 ` Dai Ngo
2026-01-20 22:03 ` Jeff Layton
2026-01-20 22:48 ` Dai Ngo
2026-01-21 14:34 ` Jeff Layton
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=20260120072638.GA6380@lst.de \
--to=hch@lst.de \
--cc=alex.aring@gmail.com \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.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.