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

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