From: Jeff Layton <jlayton@kernel.org>
To: Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>
Cc: Omar Sandoval <osandov@osandov.com>, Chris Mason <clm@fb.com>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 0/2] nfs: free leftover lsegs before freeing a layout in pnfs_put_layout_hdr
Date: Mon, 05 May 2025 10:57:34 -0400 [thread overview]
Message-ID: <9eb4aaa54fb326bc589e2936b0380da06ed008e9.camel@kernel.org> (raw)
In-Reply-To: <20250428-nfs-6-16-v1-0-2d45b80facef@kernel.org>
On Mon, 2025-04-28 at 13:24 -0700, Jeff Layton wrote:
> Sending this as an RFC as I don't have a reliable reproducer for the
> problem that Omar reported. I'm also not sure this is the best fix for
> the problem. There is probably a case to be made that the real bug is in
> the error handling for pnfs_layoutreturn_before_put_layout_hdr().
>
> My guess is that the issue is that we end up with entries on the
> plh_return_segs list just before the network goes down. That causes the
> LAYOUTRETURN to fail with something that looks retryable, and the lsegs
> on the list aren't freed.
>
> It's possible that we just need to catch ENETUNREACH in the LAYOUTRETURN
> error handling, but I'm not sure I correctly understand the problem. If
> entries are racing onto the list just before the refcount decrement,
> then that wouldn't fix it.
>
> The first patch should fix the issue of the leaked lsegs, and the second
> should let us know if it ever crops up again.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> Jeff Layton (2):
> nfs: free leftover lsegs before freeing a layout in pnfs_put_layout_hdr
> nfs: pr_warn if plh_segs or plh_return_segs are non-empty when freeing
>
> fs/nfs/pnfs.c | 23 +++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
> ---
> base-commit: 5bc1018675ec28a8a60d83b378d8c3991faa5a27
> change-id: 20250428-nfs-6-16-87062aa2989d
>
> Best regards,
Trond, Anna, ping? This seems like the right thing to do, but I'd
appreciate a second (and third) set of eyes on this.
Thanks,
--
Jeff Layton <jlayton@kernel.org>
prev parent reply other threads:[~2025-05-05 14:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 20:24 [PATCH RFC 0/2] nfs: free leftover lsegs before freeing a layout in pnfs_put_layout_hdr Jeff Layton
2025-04-28 20:24 ` [PATCH RFC 1/2] " Jeff Layton
2025-04-28 20:24 ` [PATCH RFC 2/2] nfs: pr_warn if plh_segs or plh_return_segs are non-empty when freeing Jeff Layton
2025-05-05 14:57 ` Jeff Layton [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=9eb4aaa54fb326bc589e2936b0380da06ed008e9.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=anna@kernel.org \
--cc=clm@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=osandov@osandov.com \
--cc=trondmy@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.