> > > 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.
