Re: [PATCH] fs: Do not check if there is a fsnotify watcher on pseudo inodes

Amir Goldstein
2020-06-12T20:34:31Z

> > > So maybe it would be better to list all users of alloc_file_pseudo()
> > > and say that they all should be opted out of fsnotify, without mentioning
> > > "internal mount"?
> > >
> >
> > The users are DMA buffers, CXL, aio, anon inodes, hugetlbfs, anonymous
> > pipes, shmem and sockets although not all of them necessary end up using
> > a VFS operation that triggers fsnotify. Either way, I don't think it
> > makes sense (or even possible) to watch any of those with fanotify so
> > setting the flag seems reasonable.
> >
>
> I also think this seems reasonable, but the more accurate reason IMO
> is found in the comment for d_alloc_pseudo():
> "allocate a dentry (for lookup-less filesystems)..."
>
> > I updated the changelog and maybe this is clearer.
>
> I still find the use of "internal mount" terminology too vague.
> "lookup-less filesystems" would have been more accurate,

Only it is not really accurate for shmfs anf hugetlbfs, which are
not lookup-less, they just hand out un-lookable inodes.

> because as you correctly point out, the user API to set a watch
> requires that the marked object is looked up in the filesystem.
>
> There are also some kernel internal users that set watches
> like audit and nfsd, but I think they are also only interested in
> inodes that have a path at the time that the mark is setup.
>

FWIW I verified that watches can be set on anonymous pipes
via /proc/XX/fd, so if we are going to apply this patch, I think it
should be accompanied with a complimentary patch that forbids
setting up a mark on these sort of inodes. If someone out there
is doing this, at least they would get a loud message that something
has changed instead of silently dropping fsnotify events.

So now the question is how do we identify/classify "these sort of
inodes"? If they are no common well defining characteristics, we
may need to blacklist pipes sockets and anon inodes explicitly
with S_NONOTIFY.

Thanks,
Amir.