On 13.09.2016 22:15, Jan Kara wrote:
> When freeing permission events by fsnotify_destroy_event(), the warning
> WARN_ON(!list_empty(&event->list));
> may falsely hit. This is because although fanotify_get_response() saw
> event->response set, there is nothing to make sure the current CPU also
> sees the removal of the event from the list. Add proper locking around
> the WARN_ON() to avoid the false warning.
>
> Reported-by: Miklos Szeredi <mszeredi@xxxxxxxxxx>
> Signed-off-by: Jan Kara <jack@xxxxxxx>
> ---
> fs/notify/notification.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/fs/notify/notification.c b/fs/notify/notification.c
> index 070d255b24a2..6b7f430bb2de 100644
> --- a/fs/notify/notification.c
> +++ b/fs/notify/notification.c
> @@ -73,8 +73,17 @@ void fsnotify_destroy_event(struct fsnotify_group *group,
> /* Overflow events are per-group and we don't want to free them */
> if (!event || event->mask == FS_Q_OVERFLOW)
> return;
> - /* If the event is still queued, we have a problem... */
> - WARN_ON(!list_empty(&event->list));
> + /*
> + * If the event is still queued, we have a problem... Do an unreliable
> + * lockless check first to avoid locking in the common case. The
> + * locking may be necessary for permission events which got removed
> + * from the list by a different CPU than the one freeing the event.
> + */
> + if (!list_empty(&event->list)) {
> + spin_lock(&group->notification_lock);
> + WARN_ON(!list_empty(&event->list));
> + spin_unlock(&group->notification_lock);
> + }
> group->ops->free_event(event);
> }
>
>
Reviewed-by: Lino Sanfilippo <LinoSanfilippo@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
