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: Mon, 30 Mar 2026 17:29:52 +0000 [thread overview]
Message-ID: <edbc43fe2e234c41e1c72275c176fc22dc773a58.camel@ibm.com> (raw)
In-Reply-To: <20260330084319.1357751-1-max.kellermann@ionos.com>
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>
Thanks,
Slava.
next prev parent reply other threads:[~2026-03-30 17:30 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 [this message]
2026-04-02 18:12 ` Viacheslav Dubeyko
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=edbc43fe2e234c41e1c72275c176fc22dc773a58.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
Powered by JetHome