On Mon, Jun 15, 2020 at 8:25 PM Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Jun 15, 2020 at 07:26:38PM +0300, Amir Goldstein wrote: > > On Mon, Jun 15, 2020 at 3:14 PM Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > Changelog since v1 > > > o Updated changelog > > > > Slipped to commit message > > > > It's habit, it's the layout I generally use for mm even though others > prefer having it below ---. I wasn't sure of fsnotify's preferred format > for tracking major differences between versions. > > > > > > > The kernel uses internal mounts created by kern_mount() and populated > > > with files with no lookup path by alloc_file_pseudo for a variety of > > > reasons. An example of such a mount is for anonymous pipes. For pipes, > > > every vfs_write regardless of filesystem, fsnotify_modify() is called to > > > notify of any changes which incurs a small amount of overhead in fsnotify > > > even when there are no watchers. It can also trigger for reads and readv > > > and writev, it was simply vfs_write() that was noticed first. > > > > > > A patch is pending that reduces, but does not eliminte, the overhead of > > > > typo: eliminte > > > > Yes. > > > > fsnotify but for files that cannot be looked up via a path, even that > > > small overhead is unnecessary. The user API for fanotify is based on > > > the pathname and a dirfd and proc entries appear to be the only visible > > > representation of the files. Proc does not have the same pathname as the > > > internal entry and the proc inode is not the same as the internal inode > > > so even if fanotify is used on a file under /proc/XX/fd, no useful events > > > are notified. > > > > > > > Note that fanotify is not the only uapi to add marks, but this is fine by me > > I suppose if Jan wants to he can make small corrections on commit. > > > > True but I didn't think inotify was materially different as it also takes > a path. Is that wrong or are there others that matter and can attach to > a file that cannot be looked up via a path? There are kernel/audit* and nfsd/filecache.c users, but as far as I could tell, there is no danger from there. I was just pointing out that the fanotify uapi argument alone is not a full proof. Thanks, Amir.
