[CRIU] [PATCH 2/4] fsnotify: Flush own generated events

[Andrew Vagin]

On Thu, Sep 04, 2014 at 10:23:36PM +0400, Cyrill Gorcunov wrote:
> During restore of fsnotify objects we may generate own
> events (in particular when we remove last link to hardlinked
> remap entry) but userspace application should not see any
> event coming from criu itself.
> 
> For this sake at the end of fsnotify object restore read
> flush events queue.
> 
> I'm not really yet sure that this will solve the problem
> in general, eventually it might end up that we need to
> restore fsnotify objects after _all_ files being restored,
> i.e. at very late stage of restore. But this will require
> more code changes so I stick with simplier solution first
> (and anyway we will need the helpers implemented in this
>  patch).
> 
> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
> ---
>  fsnotify.c | 118 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 114 insertions(+), 4 deletions(-)
> 
...
> +	/*
> +	 * Make it nonblock by default, to flush own generated
> +	 * events, and then restore it back.
> +	 */
> +	flags = info->ffe->faflags | FAN_NONBLOCK;
>  	if (info->ffe->flags & O_CLOEXEC)
>  		flags |= FAN_CLOEXEC;
> -	if (info->ffe->flags & O_NONBLOCK)
> -		flags |= FAN_NONBLOCK;
>  
>  	tmp = sys_fanotify_init(flags, info->ffe->evflags);
>  	if (tmp < 0) {
> @@ -632,6 +731,17 @@ static int open_fanotify_fd(struct file_desc *d)
>  	if (restore_fown(tmp, info->ffe->fown))
>  		goto err;
>  
> +	if (flush_inotify_events(tmp, info->ffe->id))

flush_inotify_events() can't be used for fanotifies, because fanorify
events are described by "struct fanotify_event_metadata"

> +		goto err;
> +
> +	if (!(info->ffe->faflags & O_NONBLOCK)) {
> +		if (fcntl(tmp, F_SETFD, fcntl(tmp, F_GETFD) | O_NONBLOCK)) {
> +			pr_perror("Can't restore fanotify flags on 0x%08x",
> +				  info->ffe->id);
> +			return -1;
> +		}
> +	}
> +
>  	return tmp;
>  err:
>  	close_safe(&tmp);
> -- 
> 1.9.3
>