> On 15 Mar 2018, at 02:55, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > > On Wed, Mar 14, 2018 at 1:14 AM Yan, Zheng <ukernel@xxxxxxxxx> wrote: > On Tue, Mar 13, 2018 at 7:52 PM, Chengguang Xu <cgxu519@xxxxxxx> wrote: > > Obviously wrong mutex lock/unlock for nothing. > > > > Signed-off-by: Chengguang Xu <cgxu519@xxxxxxx> > > --- > > fs/ceph/mds_client.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c > > index 8fc37a8..5439dfd 100644 > > --- a/fs/ceph/mds_client.c > > +++ b/fs/ceph/mds_client.c > > @@ -3514,8 +3514,6 @@ static void drop_leases(struct ceph_mds_client *mdsc) > > if (!s) > > continue; > > mutex_unlock(&mdsc->mutex); > > - mutex_lock(&s->s_mutex); > > - mutex_unlock(&s->s_mutex); > > ceph_put_mds_session(s); > > mutex_lock(&mdsc->mutex); > > } > > -- > > 1.8.3.1 > > > Applied, thanks > Yan, Zheng > > So I'm sure it's not the case, but when I saw this go by I was assuming that the mutex grab is to make sure we don't have anybody still running in a critical section that assumes those caps are held. Is that not an issue and/or definitely not the case? :) > -Greg I think you are right. Thanks Yan, Zheng -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
