Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp336477pxb; Mon, 16 Aug 2021 06:36:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNalxKIPQczYX8laoMD5e4wkdyPALcyKsOBK2W3tnM7sUocNZlvWLTUuCtjyVxZ+ziTOZq X-Received: by 2002:a17:906:87c2:: with SMTP id zb2mr16170058ejb.322.1629120967474; Mon, 16 Aug 2021 06:36:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629120967; cv=none; d=google.com; s=arc-20160816; b=sLW7wJNSE5da+gyEf3aei460zgOBujnJbsp7IThs1Lp6CkSiLvQMjW1L5q+GmOcElc kvTPRnpMyDkXCuh9J2TpEtYuQ+ycxvtimP5wOphVIAx9Ho6aLUvy96ZM6wNQQRXOnuDf gFTvjspB8/Ym8Qwl4jVgrwI7GhpwLPDVMPwxGC+Y/pOzWI1hZvmnXTr1dQkpaMiZGy+n jbkz07BEuCTrpF2k/olr8bqq3yy7a/J0bhaDvCOtFNuEBmw7EB3JKgJe6Gsb91OeI8fV EVHqihPeRqLTyK9Flkr9EbeAZIr5z9LC+TI182RIGq9+mlAwJt1CYwt2w9Qifqqa4H6B TtPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Lq7Wtsnfx9SBFehxlMrxQ9Fa+xgT1LGx3P0VJ1hKtn4=; b=u/kzrUoK5CGsWzqSf8wB+GeK8k+5svNuhAAE1JJ3CJJmT94ktsnWqTi0qu2pk4Z2KO vfthmuhrG//2OtSTsEgJCkCQAe36mJ2eHZZNZSAg6DJ3g1upjrqOhT9bRUezCY8KLeqi kRSHAUDIQkAGEB5Z0bcoZVeSgtgwr30f54z5VsK5oO3KTdrOnd+L0+hYBFcNs3/Uv3L7 CGVg9FPDB//v4KC/9DoLHzzEKAQAeUU/ldnas23OOB+8Qc5yd8iIQZ3YMo8znCwisxGH UvgrKgWg/vN0UEn8YcpQY+Zo5dfnAJ3Do0g34He0JOWnEG8uDrLW5/6OitWCx8A0oPjR bXTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DwzKRXGK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n15si10876016edy.243.2021.08.16.06.35.44; Mon, 16 Aug 2021 06:36:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DwzKRXGK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241307AbhHPNco (ORCPT + 99 others); Mon, 16 Aug 2021 09:32:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:44514 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240962AbhHPNU0 (ORCPT ); Mon, 16 Aug 2021 09:20:26 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E505463305; Mon, 16 Aug 2021 13:15:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1629119755; bh=SiPgRGHbGQySDNfy3OJn4o1z2BoGp7oudsaI9vqwVuA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DwzKRXGK6+rV+kqWOoeU0wuMlpUmB+HlM8fM15RqFWmEI1/RGM+5RedlfUPrech3x 6V1wlt0sTgcWLi20pEz2kDv2l2Mlyz0b3JR1GhGkN+s+5mXuc+2ozowMxAZnOzoap0 tdE7Z8VCr/KuvyefiaZV1asLeBEpr/aXKhd2Qi+0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jeff Layton , Ilya Dryomov Subject: [PATCH 5.13 149/151] ceph: clean up locking annotation for ceph_get_snap_realm and __lookup_snap_realm Date: Mon, 16 Aug 2021 15:02:59 +0200 Message-Id: <20210816125448.990001213@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210816125444.082226187@linuxfoundation.org> References: <20210816125444.082226187@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jeff Layton commit df2c0cb7f8e8c83e495260ad86df8c5da947f2a7 upstream. They both say that the snap_rwsem must be held for write, but I don't see any real reason for it, and it's not currently always called that way. The lookup is just walking the rbtree, so holding it for read should be fine there. The "get" is bumping the refcount and (possibly) removing it from the empty list. I see no need to hold the snap_rwsem for write for that. Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman --- fs/ceph/snap.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/fs/ceph/snap.c +++ b/fs/ceph/snap.c @@ -60,12 +60,12 @@ /* * increase ref count for the realm * - * caller must hold snap_rwsem for write. + * caller must hold snap_rwsem. */ void ceph_get_snap_realm(struct ceph_mds_client *mdsc, struct ceph_snap_realm *realm) { - lockdep_assert_held_write(&mdsc->snap_rwsem); + lockdep_assert_held(&mdsc->snap_rwsem); dout("get_realm %p %d -> %d\n", realm, atomic_read(&realm->nref), atomic_read(&realm->nref)+1); @@ -139,7 +139,7 @@ static struct ceph_snap_realm *ceph_crea /* * lookup the realm rooted at @ino. * - * caller must hold snap_rwsem for write. + * caller must hold snap_rwsem. */ static struct ceph_snap_realm *__lookup_snap_realm(struct ceph_mds_client *mdsc, u64 ino) @@ -147,7 +147,7 @@ static struct ceph_snap_realm *__lookup_ struct rb_node *n = mdsc->snap_realms.rb_node; struct ceph_snap_realm *r; - lockdep_assert_held_write(&mdsc->snap_rwsem); + lockdep_assert_held(&mdsc->snap_rwsem); while (n) { r = rb_entry(n, struct ceph_snap_realm, node);