From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
To: "max.kellermann@ionos.com" <max.kellermann@ionos.com>,
"idryomov@gmail.com" <idryomov@gmail.com>,
Alex Markuze <amarkuze@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: RE: [PATCH] ceph: clear `s_cap_reconnect` when ceph_pagelist_encode_32() fails
Date: Thu, 2 Apr 2026 18:12:53 +0000 [thread overview]
Message-ID: <a14adf2a0b021ca604d1de2252b3c63593b4b001.camel@ibm.com> (raw)
In-Reply-To: <edbc43fe2e234c41e1c72275c176fc22dc773a58.camel@ibm.com>
On Mon, 2026-03-30 at 17:29 +0000, Viacheslav Dubeyko wrote:
> On Mon, 2026-03-30 at 10:43 +0200, Max Kellermann wrote:
> > This MDS reconnect error path leaves s_cap_reconnect set.
> > send_mds_reconnect() sets the bit at the beginning of the reconnect,
> > but the first failing operation after that, ceph_pagelist_encode_32(),
> > can jump to `fail:` without clearing it.
> >
> > __ceph_remove_cap() consults that flag to decide whether cap releases
> > should be queued. A reconnect-preparation failure therefore leaves the
> > session in reconnect mode from the cap-release path's point of view
> > and can strand release work until some later state transition repairs
> > it.
> >
> > Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
> > ---
> > fs/ceph/mds_client.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
> > index b1746273f186..4fa471d9b3b2 100644
> > --- a/fs/ceph/mds_client.c
> > +++ b/fs/ceph/mds_client.c
> > @@ -4956,7 +4956,7 @@ static void send_mds_reconnect(struct ceph_mds_client *mdsc,
> > /* placeholder for nr_caps */
> > err = ceph_pagelist_encode_32(recon_state.pagelist, 0);
> > if (err)
> > - goto fail;
> > + goto fail_clear_cap_reconnect;
> >
> > if (test_bit(CEPHFS_FEATURE_MULTI_RECONNECT, &session->s_features)) {
> > recon_state.msg_version = 3;
> > @@ -5046,6 +5046,10 @@ static void send_mds_reconnect(struct ceph_mds_client *mdsc,
> > ceph_pagelist_release(recon_state.pagelist);
> > return;
> >
> > +fail_clear_cap_reconnect:
> > + spin_lock(&session->s_cap_lock);
> > + session->s_cap_reconnect = 0;
> > + spin_unlock(&session->s_cap_lock);
> > fail:
> > ceph_msg_put(reply);
> > up_read(&mdsc->snap_rwsem);
>
> Makes sense. Nice fix. But, maybe, we need to consider refactoring of this
> function because of such issue.
>
> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>
>
The xfstests run on 7.0-rc6 didn't reveal any new issues related to the patch.
Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Thanks,
Slava.
next prev parent reply other threads:[~2026-04-02 18:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 8:43 Max Kellermann
2026-03-30 17:29 ` Viacheslav Dubeyko
2026-04-02 18:12 ` Viacheslav Dubeyko [this message]
2026-04-02 18:32 ` Viacheslav Dubeyko
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=a14adf2a0b021ca604d1de2252b3c63593b4b001.camel@ibm.com \
--to=slava.dubeyko@ibm.com \
--cc=amarkuze@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=max.kellermann@ionos.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®