From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68EE6EB64DD for ; Wed, 9 Aug 2023 11:20:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233528AbjHILUj (ORCPT ); Wed, 9 Aug 2023 07:20:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33390 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233530AbjHILUh (ORCPT ); Wed, 9 Aug 2023 07:20:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C14CEED for ; Wed, 9 Aug 2023 04:20:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5731F631D3 for ; Wed, 9 Aug 2023 11:20:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65786C433C8; Wed, 9 Aug 2023 11:20:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1691580035; bh=ZJchF7m3ZrlQJP4mwQBqgjadwArwlQ50Xl/dE38mYjA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lr3Pzqyy9Dg4iFTn6gYhyF9dWRyDE/+omqFxwH/aHlOr4V8FjZqbdbXoO8RDEWFi7 AZ2rjgwR0iwzQid4ffih36C+EBnP/WgUH7JoS1DLXFzplRckzDTZ9QAt+O+n0Ep5b+ GE72m/fSTHTsjflgXcF8EWEC5n0UYAvPqIhKX5wE= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Xiubo Li , Milind Changire , Patrick Donnelly , Ilya Dryomov Subject: [PATCH 4.19 174/323] ceph: dont let check_caps skip sending responses for revoke msgs Date: Wed, 9 Aug 2023 12:40:12 +0200 Message-ID: <20230809103706.108145941@linuxfoundation.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230809103658.104386911@linuxfoundation.org> References: <20230809103658.104386911@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Xiubo Li commit 257e6172ab36ebbe295a6c9ee9a9dd0fe54c1dc2 upstream. If a client sends out a cap update dropping caps with the prior 'seq' just before an incoming cap revoke request, then the client may drop the revoke because it believes it's already released the requested capabilities. This causes the MDS to wait indefinitely for the client to respond to the revoke. It's therefore always a good idea to ack the cap revoke request with the bumped up 'seq'. Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/61782 Signed-off-by: Xiubo Li Reviewed-by: Milind Changire Reviewed-by: Patrick Donnelly Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman --- fs/ceph/caps.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -3285,6 +3285,15 @@ static void handle_cap_grant(struct inod } BUG_ON(cap->issued & ~cap->implemented); + /* don't let check_caps skip sending a response to MDS for revoke msgs */ + if (le32_to_cpu(grant->op) == CEPH_CAP_OP_REVOKE) { + cap->mds_wanted = 0; + if (cap == ci->i_auth_cap) + check_caps = 1; /* check auth cap only */ + else + check_caps = 2; /* check all caps */ + } + if (extra_info->inline_version > 0 && extra_info->inline_version >= ci->i_inline_version) { ci->i_inline_version = extra_info->inline_version;