From: Sean Chang <seanwascoding@gmail.com>
To: Benjamin Coddington <ben.coddington@hammerspace.com>
Cc: Jeff Layton <jlayton@kernel.org>,
trondmy@kernel.org, anna@kernel.org, linux-nfs@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] NFS: Fix RCU dereference of cl_xprt in nfs_compare_super_address
Date: Mon, 20 Apr 2026 00:06:30 +0800 [thread overview]
Message-ID: <CAAb=EJWsP_j-u+7Tqb3-7Fh3adRDhjOAGo-HF69xEB-kkCoqiA@mail.gmail.com> (raw)
In-Reply-To: <35E1BD18-1B61-4F71-B50A-D1C830760562@hammerspace.com>
On Sun, Apr 19, 2026 at 9:52 PM Benjamin Coddington
<ben.coddington@hammerspace.com> wrote:
>
>
> > +
> > + if (!xprt1 || !xprt2 ||
> > + !test_bit(XPRT_CONNECTED, &xprt1->state) ||
> > + !test_bit(XPRT_CONNECTED, &xprt2->state))
> > + goto out_unlock;
>
> ^^ I really don't think this check is necessary. Aren't we only ever
> comparing with one freshly created, and the other looked up holding sb_lock?
>
> I'm doubtful this hunk is fixing a real problem.
>
Hi Ben,
Thanks for the clarification.
You're right. I've traced the call path and confirmed that
nfs_compare_super() is called by sget_fc() while holding
the global sb_lock. This ensures the existence and stability
of the existing superblocks and their associated transports
during the comparison.
Since the connection state doesn't affect the identity of the
server, I'll remove the redundant test_bit and pointer checks and send out v3.
Thanks,
Sean
prev parent reply other threads:[~2026-04-19 16:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-19 10:01 [PATCH v2 0/2] NFS: fix RCU and tracing pointer safety Sean Chang
2026-04-19 10:01 ` [PATCH v2 1/2] NFS: remove redundant __private attribute from nfs_page_class Sean Chang
2026-04-19 13:42 ` Benjamin Coddington
2026-04-19 10:01 ` [PATCH v2 2/2] NFS: Fix RCU dereference of cl_xprt in nfs_compare_super_address Sean Chang
2026-04-19 13:52 ` Benjamin Coddington
2026-04-19 16:06 ` Sean Chang [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='CAAb=EJWsP_j-u+7Tqb3-7Fh3adRDhjOAGo-HF69xEB-kkCoqiA@mail.gmail.com' \
--to=seanwascoding@gmail.com \
--cc=anna@kernel.org \
--cc=ben.coddington@hammerspace.com \
--cc=jlayton@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--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 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 read-only IMAP folder(s) and NNTP newsgroup(s).