Re: [PATCH] ceph: delete unnecessary mutex lock/unlock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 15, 2018 at 2:06 PM, Chengguang Xu <cgxu519@xxxxxxx> wrote:
>> Sent: Thursday, March 15, 2018 at 7:58 AM
>> From: "Yan, Zheng" <zyan@xxxxxxxxxx>
>> To: "Gregory Farnum" <gfarnum@xxxxxxxxxx>
>> Cc: "Zheng Yan" <ukernel@xxxxxxxxx>, "Chengguang Xu" <cgxu519@xxxxxxx>, "Ilya Dryomov" <idryomov@xxxxxxxxx>, ceph-devel <ceph-devel@xxxxxxxxxxxxxxx>
>> Subject: Re: [PATCH] ceph: delete unnecessary mutex lock/unlock
>>
>>
>>
>> > 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? :)
>
> I understand the purpose of the lock here now, but it does not always look safe.
> Won't any bad things happen by timing?

What timing are you concerned about? The requirement in this function
is to drop our leases and make sure there are no users left. By
updating the data structures we prevent new users; by locking the
mutex we ensure there are no concurrent threads still making use of
the leases.
-Greg
--
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



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux