Fix a leak in s_fsnotify_connectors counter in case of a race between
concurrent add of new fsnotify mark to an object.
The task that lost the race fails to drop the counter before freeing
the unused connector.
Following umount() hangs in fsnotify_sb_delete()/wait_var_event(),
because s_fsnotify_connectors never drops to zero.
Fixes: ec44610fe2b8 ("fsnotify: count all objects with attached connectors")
Reported-by: Murphy Zhou <jencce.kernel@xxxxxxxxx>
Link: https://lore.kernel.org/linux-fsdevel/20210907063338.ycaw6wvhzrfsfdlp@xxxxxxxxxxxxxxxxxxxxxxxxx/
Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
---
Hi Linus,
Jan is on vacation for the duration of the merge window and he
asked me to step in for him in case something went wrong, so
of course something went wrong :)
Please apply this fix to a regression in code that was merged for
v5.15-rc1.
I think you will find the fix is obvious and I also verified the
fix with the reproducer provided by Murphy.
For context (and for bragging), the merged code improves the fast
path for workloads that do not involve fsnotify and has reported to
improve performance by 5-10% for some general workloads [1][2].
Thanks,
Amir.
[1] https://lore.kernel.org/lkml/20210831025623.GC4286@xsang-OptiPlex-9020/
[2] https://lore.kernel.org/lkml/20210808143425.GE27482@xsang-OptiPlex-9020/
fs/notify/mark.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/notify/mark.c b/fs/notify/mark.c
index 95006d1d29ab..fa1d99101f89 100644
--- a/fs/notify/mark.c
+++ b/fs/notify/mark.c
@@ -531,6 +531,7 @@ static int fsnotify_attach_connector_to_object(fsnotify_connp_t *connp,
/* Someone else created list structure for us */
if (inode)
fsnotify_put_inode_ref(inode);
+ fsnotify_put_sb_connectors(conn);
kmem_cache_free(fsnotify_mark_connector_cachep, conn);
}
--
2.25.1
