[CRIU] [PATCH] fsmptify: Filter out internal inotify bits when restoring marks

[Cyrill Gorcunov]

On Wed, Sep 23, 2015 at 03:00:57PM +0300, Andrew Vagin wrote:
> On Tue, Sep 22, 2015 at 05:21:42PM +0300, Cyrill Gorcunov wrote:
> > On Tue, Sep 22, 2015 at 04:48:40PM +0300, Andrew Vagin wrote:
> > > > 
> > > > You miss the point. It was a bug in the kernel that it has been exporting
> > > > internal bit into userspace. The kernel has _all_ rights to
> > > > 
> > > > #define IN_SOME_NEW_BIT	 	0x08000000
> > > 
> > > Now I'm agree that my idea isn't good, but I don't like to use
> > > IN_ALL_EVENTS too :-P
> > 
> > I understand that. By using IN_ALL_EVENTS we are limiting criu
> > and make it bound to the environment it has been built on.
> > So, maybe don't patch criu at all? I thought we're failing in
> > the tests actually.
> 
> An user can dump processes on an old kernel and then restore them on
> a new one. We don't check this case in our tests.

Yes, but the thing is that -- the bit get filtered out by the kernel
at the moment (in add-watch syscall)

static inline __u32 inotify_arg_to_mask(u32 arg)
{
	__u32 mask;

	mask = (FS_IN_IGNORED | FS_EVENT_ON_CHILD | FS_UNMOUNT);

	/* mask off the flags used to open the fd */
	mask |= (arg & (IN_ALL_EVENTS | IN_ONESHOT | IN_EXCL_UNLINK));

	return mask;
}

so if one day this bit become a valid for userspace I suspect it
wont happen in a 3-4 releases thus I don't expect we hit any
problem soon.