diff options
author | Jan Kara <jack@suse.cz> | 2018-02-21 15:07:52 +0100 |
---|---|---|
committer | Jan Kara <jack@suse.cz> | 2018-02-27 10:25:33 +0100 |
commit | 7b1f641776e0c8b824fb10135168e4b683a9e2ba (patch) | |
tree | 80f394d89521008b6bcbc980e202d25d7f35973f /fs/notify/fanotify | |
parent | 1f5eaa90010ed7cf0ae90a526c48657d02c6086f (diff) |
fsnotify: Let userspace know about lost events due to ENOMEM
Currently if notification event is lost due to event allocation failing
we ENOMEM, we just silently continue (except for fanotify permission
events where we deny the access). This is undesirable as userspace has
no way of knowing whether the notifications it got are complete or not.
Treat lost events due to ENOMEM the same way as lost events due to queue
overflow so that userspace knows something bad happened and it likely
needs to rescan the filesystem.
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Diffstat (limited to 'fs/notify/fanotify')
-rw-r--r-- | fs/notify/fanotify/fanotify.c | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index 928f2a5eedb7..d51e1bb781cf 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -221,8 +221,15 @@ static int fanotify_handle_event(struct fsnotify_group *group, event = fanotify_alloc_event(group, inode, mask, data); ret = -ENOMEM; - if (unlikely(!event)) + if (unlikely(!event)) { + /* + * We don't queue overflow events for permission events as + * there the access is denied and so no event is in fact lost. + */ + if (!fanotify_is_perm_event(mask)) + fsnotify_queue_overflow(group); goto finish; + } fsn_event = &event->fse; ret = fsnotify_add_event(group, fsn_event, fanotify_merge); |