| Message ID | 20210909115634.1015564-1-amir73il@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fsnotify: fix sb_connectors leak | expand |
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); }
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@gmail.com> Link: https://lore.kernel.org/linux-fsdevel/20210907063338.ycaw6wvhzrfsfdlp@xzhoux.usersys.redhat.com/ Signed-off-by: Amir Goldstein <amir73il@gmail.com> --- 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(+)