From: Jeff Layton <jlayton@kernel.org>
To: Niels Dossche <dossche.niels@gmail.com>, ceph-devel@vger.kernel.org
Cc: Ilya Dryomov <idryomov@gmail.com>
Subject: Re: [PATCH v2] ceph: get snap_rwsem read lock in handle_cap_export for ceph_add_cap
Date: Wed, 16 Mar 2022 10:12:14 -0400 [thread overview]
Message-ID: <53f0a25ce305b60d02d0d9ac8ea0be192cdcfbc0.camel@kernel.org> (raw)
In-Reply-To: <20220315152946.12912-1-dossche.niels@gmail.com>
On Tue, 2022-03-15 at 16:29 +0100, Niels Dossche wrote:
> ceph_add_cap says in its function documentation that the caller should
> hold the read lock on the session snap_rwsem. Furthermore, not only
> ceph_add_cap needs that lock, when it calls to ceph_lookup_snap_realm it
> eventually calls ceph_get_snap_realm which states via lockdep that
> snap_rwsem needs to be held. handle_cap_export calls ceph_add_cap
> without that mdsc->snap_rwsem held. Thus, since ceph_get_snap_realm
> and ceph_add_cap both need the lock, the common place to acquire that
> lock is inside handle_cap_export.
>
> Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
> ---
> fs/ceph/caps.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> index b472cd066d1c..a23cf2a528bc 100644
> --- a/fs/ceph/caps.c
> +++ b/fs/ceph/caps.c
> @@ -3856,6 +3856,7 @@ static void handle_cap_export(struct inode *inode, struct ceph_mds_caps *ex,
> dout("handle_cap_export inode %p ci %p mds%d mseq %d target %d\n",
> inode, ci, mds, mseq, target);
> retry:
> + down_read(&mdsc->snap_rwsem);
> spin_lock(&ci->i_ceph_lock);
> cap = __get_cap_for_mds(ci, mds);
> if (!cap || cap->cap_id != le64_to_cpu(ex->cap_id))
> @@ -3919,6 +3920,7 @@ static void handle_cap_export(struct inode *inode, struct ceph_mds_caps *ex,
> }
>
> spin_unlock(&ci->i_ceph_lock);
> + up_read(&mdsc->snap_rwsem);
> mutex_unlock(&session->s_mutex);
>
> /* open target session */
> @@ -3944,6 +3946,7 @@ static void handle_cap_export(struct inode *inode, struct ceph_mds_caps *ex,
>
> out_unlock:
> spin_unlock(&ci->i_ceph_lock);
> + up_read(&mdsc->snap_rwsem);
> mutex_unlock(&session->s_mutex);
> if (tsession) {
> mutex_unlock(&tsession->s_mutex);
Looks good. Merged into testing branch.
Thanks!
--
Jeff Layton <jlayton@kernel.org>
prev parent reply other threads:[~2022-03-16 14:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-15 15:29 [PATCH v2] ceph: get snap_rwsem read lock in handle_cap_export for ceph_add_cap Niels Dossche
2022-03-16 4:30 ` Xiubo Li
2022-03-16 14:12 ` Jeff Layton [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=53f0a25ce305b60d02d0d9ac8ea0be192cdcfbc0.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=dossche.niels@gmail.com \
--cc=idryomov@gmail.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