Ocfs2 devel - Jul 2022 - [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 at
wanadoo.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)
> 
>

From: Christophe JAILLET
> Sent: 19 July 2022 14:25
> 
> 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?
Indeed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)

On 7/19/22 9:25 PM, Christophe JAILLET wrote:
> 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)
 
osb_lock is to protect osb filed such as 'osb_orphan_wipes', while
node_map_lock is to protect the node map 'osb_recovering_orphan_dirs'
specifically.

Thanks,
Joseph