On (25/05/26 23:12), Sergey Senozhatsky wrote:
[..]
> > > schedule+0x534/0x2540
> > > fsnotify_destroy_group+0xa7/0x150
> > > fanotify_release+0x147/0x160
> > > ____fput+0xe4/0x2a0
> > > task_work_run+0x71/0xb0
> > > do_exit+0x1ea/0x800
> > > do_group_exit+0x81/0x90
> > > get_signal+0x32d/0x4e0
[..]
> @@ -945,8 +945,10 @@ static int fanotify_handle_event(struct fsnotify_group *group, u32 mask,
> if (FAN_GROUP_FLAG(group, FANOTIFY_FID_BITS)) {
> fsid = fanotify_get_fsid(iter_info);
> /* Racing with mark destruction or creation? */
> - if (!fsid.val[0] && !fsid.val[1])
> - return 0;
> + if (!fsid.val[0] && !fsid.val[1]) {
> + ret = 0;
> + goto finish;
> + }
> }
Surprisingly enough, this did not help.
Jan, one more silly question:
fsnotify_get_mark_safe() and fsnotify_put_mark_wake() can be called on
NULL mark. Is it possible that between fsnotify_prepare_user_wait(iter_info)
and fsnotify_finish_user_wait(iter_info) iter_info->marks[type] changes in
such a way that creates imbalance? That is, fsnotify_finish_user_wait() sees
more NULL marks and hence does not rollback all the group->user_waits
increments that fsnotify_prepare_user_wait() did?
