On Wed, May 29, 2019 at 10:46:36AM -0700, Wengang Wang wrote:
> ocfs2_dentry_attach_lock() can be executed in parallel threads against the
> same dentry. Make that race safe.
> The race is like this:
>
> thread A thread B
>
> (A1) enter ocfs2_dentry_attach_lock,
> seeing dentry->d_fsdata is NULL,
> and no alias found by
> ocfs2_find_local_alias, so kmalloc
> a new ocfs2_dentry_lock structure
> to local variable "dl", dl1
>
> .....
>
> (B1) enter ocfs2_dentry_attach_lock,
> seeing dentry->d_fsdata is NULL,
> and no alias found by
> ocfs2_find_local_alias so kmalloc
> a new ocfs2_dentry_lock structure
> to local variable "dl", dl2.
>
> ......
>
> (A2) set dentry->d_fsdata with dl1,
> call ocfs2_dentry_lock() and increase
> dl1->dl_lockres.l_ro_holders to 1 on
> success.
> ......
>
> (B2) set dentry->d_fsdata with dl2
> call ocfs2_dentry_lock() and increase
> dl2->dl_lockres.l_ro_holders to 1 on
> success.
>
> ......
>
> (A3) call ocfs2_dentry_unlock()
> and decrease
> dl2->dl_lockres.l_ro_holders to 0
> on success.
> ....
>
> (B3) call ocfs2_dentry_unlock(),
> decreasing
> dl2->dl_lockres.l_ro_holders, but
> see it's zero now, panic
>
> Signed-off-by: Wengang Wang <wen.gang.wang@xxxxxxxxxx>
> Reported-by: Daniel Sobe <daniel.sobe@xxxxxxx>
> Tested-by: Daniel Sobe <daniel.sobe@xxxxxxx>
> Reviewed-by: Changwei Ge <gechangwei@xxxxxxx>
> ---
> v4: return in place on race detection.
>
> v3: add Reviewed-by, Reported-by and Tested-by only
>
> v2: 1) removed lock on dentry_attach_lock at the first access of
> dentry->d_fsdata since it helps very little.
> 2) do cleanups before freeing the duplicated dl
> 3) return after freeing the duplicated dl found.
> ---
>
> fs/ocfs2/dcache.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
