Re: [bug report] Potential atomicity bug in fs/ocfs2/stack_user.c, between ocfs2_control_release() and ocfs2_control_install_private()

In normal o2cb operation a single ocfs2_controld daemon holds one fd, so
two concurrent valid opens are atypical.
But nothing in the code enforces single-open, so the race is genuinely
reachable.
I'll send a patch to fix it. Thanks.

On 6/1/26 5:18 PM, Ginger wrote:
> Dear Linux kernel maintainers,
> 
> My research-based static analyzer found a potential atomicity bug
> within the 'fs/ocfs2' subsystem, more specifically, in
> 'fs/ocfs2/stack_user.c'.
> 
> This potential issue is present as of git commit
> eb3f4b7426cfd2b79d65b7d37155480b32259a11 of the mainline kernel.
> 
> Potential concurrent triggering executions:
> T0:
> ocfs2_control_release
>      --> mutex_lock(&ocfs2_control_lock);
>      --> atomic_dec_and_test(&ocfs2_control_opened)
>      --> mutex_unlock(&ocfs2_control_lock);
> 
> T1:
> ocfs2_control_install_private
>     --> mutex_unlock(&ocfs2_control_lock);
>     --> atomic_inc(&ocfs2_control_opened);
> 
> The atomic_inc to 'ocfs2_control_opened' in 'ocfs2_control_install_private'
> is not protected by 'ocfs2_control_lock'.
> Therefore, it might be possible for T0 to clear ocfs2's global state after
> 'atomic_dec_and_test' gets zeroed atomic values, while T1 blindly increments
> the atomic value.
> 
> Please kindly check at your convenience. Thank you for your time and
> consideration.
> 
> Best regards,
> Ginger