[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29c3fbdd-7695-46c5-bb75-fe358c574ab3@wanadoo.fr>
Date: Tue, 19 Jul 2022 15:25:11 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: David Laight <David.Laight@...LAB.COM>,
Mark Fasheh <mark@...heh.com>,
Joel Becker <jlbec@...lplan.org>,
Joseph Qi <joseph.qi@...ux.alibaba.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>,
"ocfs2-devel@....oracle.com" <ocfs2-devel@....oracle.com>
Subject: Re: [PATCH 2/3] ocfs2: Remove a useless spinlock
Le 19/07/2022 à 12:24, David Laight a écrit :
> From: Christophe JAILLET
>> Sent: 19 July 2022 11:02
>>
>> 'node_map_lock' is a spinlock only used to protect calls to set_bit(),
>> clear_bit() and test_bit().
>>
>> {set|clear}_bit() are already atomic and don't need this extra spinlock.
>> test_bit() only reads the bitmap for a given bit.
>>
>> Remove this useless spinlock.
>
> It looks to me like the calling code is racy
> unless there is another lock in the callers.
The call chains are:
ocfs2_recover_orphans()
ocfs2_mark_recovering_orphan_dir()
spin_lock(&osb->osb_lock); <-- osb_lock spinlock
ocfs2_node_map_set_bit() <-- uses node_map_lock
...
spin_unlock(&osb->osb_lock);
...
ocfs2_clear_recovering_orphan_dir()
ocfs2_node_map_clear_bit() <-- uses node_map_lock
osb_lock is NOT taken
ocfs2_check_orphan_recovery_state()
spin_lock(&osb->osb_lock); <-- osb_lock spinlock
...
ocfs2_node_map_test_bit() <-- uses node_map_lock
...
spin_unlock(&osb->osb_lock);
So the code looks already protected by the 'osb_lock' spinlock, but I
don't know this code and ocfs2_mark_recovering_orphan_dir() looks tricky
to me. (so some other eyes are much welcome)
> While map->map is protected, the result of test_bit()
> is stale - so can't be used for much.
>
Anyway, should there be a locking issue, it is there with or without my
patch, right?
CJ
> David
>
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
>> ---
>> test_bit() is NOT documented as an atomic function. However, I can't see
>> how it could return a wrong result here.
>>
>> So review with care. There is maybe something I don't think about that is
>> lurking here.
>> ---
>> fs/ocfs2/heartbeat.c | 11 ++++-------
>> fs/ocfs2/ocfs2.h | 2 --
>> 2 files changed, 4 insertions(+), 9 deletions(-)
>>
>> diff --git a/fs/ocfs2/heartbeat.c b/fs/ocfs2/heartbeat.c
>> index 1d72e0788943..4863ad35c242 100644
>> --- a/fs/ocfs2/heartbeat.c
>> +++ b/fs/ocfs2/heartbeat.c
>> @@ -35,7 +35,6 @@ static void ocfs2_node_map_init(struct ocfs2_node_map *map)
>>
>> void ocfs2_init_node_maps(struct ocfs2_super *osb)
>> {
>> - spin_lock_init(&osb->node_map_lock);
>> ocfs2_node_map_init(&osb->osb_recovering_orphan_dirs);
>> }
>>
>> @@ -67,9 +66,8 @@ void ocfs2_node_map_set_bit(struct ocfs2_super *osb,
>> if (bit==-1)
>> return;
>> BUG_ON(bit >= map->num_nodes);
>> - spin_lock(&osb->node_map_lock);
>> +
>> set_bit(bit, map->map);
>> - spin_unlock(&osb->node_map_lock);
>> }
>>
>> void ocfs2_node_map_clear_bit(struct ocfs2_super *osb,
>> @@ -79,9 +77,8 @@ void ocfs2_node_map_clear_bit(struct ocfs2_super *osb,
>> if (bit==-1)
>> return;
>> BUG_ON(bit >= map->num_nodes);
>> - spin_lock(&osb->node_map_lock);
>> +
>> clear_bit(bit, map->map);
>> - spin_unlock(&osb->node_map_lock);
>> }
>>
>> int ocfs2_node_map_test_bit(struct ocfs2_super *osb,
>> @@ -89,13 +86,13 @@ int ocfs2_node_map_test_bit(struct ocfs2_super *osb,
>> int bit)
>> {
>> int ret;
>> +
>> if (bit >= map->num_nodes) {
>> mlog(ML_ERROR, "bit=%d map->num_nodes=%d\n", bit, map->num_nodes);
>> BUG();
>> }
>> - spin_lock(&osb->node_map_lock);
>> +
>> ret = test_bit(bit, map->map);
>> - spin_unlock(&osb->node_map_lock);
>> return ret;
>> }
>>
>> diff --git a/fs/ocfs2/ocfs2.h b/fs/ocfs2/ocfs2.h
>> index 740b64238312..1df193b97c30 100644
>> --- a/fs/ocfs2/ocfs2.h
>> +++ b/fs/ocfs2/ocfs2.h
>> @@ -302,8 +302,6 @@ struct ocfs2_super
>>
>> u32 *slot_recovery_generations;
>>
>> - spinlock_t node_map_lock;
>> -
>> u64 root_blkno;
>> u64 system_dir_blkno;
>> u64 bitmap_blkno;
>> --
>> 2.34.1
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>
>
Powered by blists - more mailing lists