On Sun, Mar 19, 2017 at 2:04 PM, Jan Kara <jack@xxxxxxx> wrote: > On Sun 19-03-17 11:37:39, Filip Štědronský wrote: >> On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: >> > However if you can really call fsnotify hooks with 'path' available in all >> > the places, it should be equally hard to just pass 'path' to >> > vfs_(create|mkdir|...) and that way we don't have to sprinkle fsnotify >> > calls into several call sites but keep them local to vfs_(create|mkdir|...) >> > helpers. Hmm? >> >> the problem is: not absolutely all. One illuminating example is the use >> of vfs_mknod in devtmpfs. There a struct path is not only unavailable >> but makes not semantic sense: the changes do not go thru any mountpoint. > > How come? In current kernel the call looks like: > > vfs_mknod(d_inode(path.dentry), dentry, mode, dev->devt); > > so the path is available there... I've actually quickly checked all > vfs_mknod() callers and they all seem to have path available. > >> And in general I think there will be situations where you would need >> to call VFS functions without paths. >> >> Thus I suggested either >> (a) wrapping the VFS functions with path variants, or >> (b) giving them an optional vfsmount argument that can be set to NULL >> when it does not make sense > > So my first take is that fsnotify calls happen still relatively high in the > call stack where we should mostly have mount point available from the path > lookup. That being said there may be places where we've lost that > information and it will not be easy to propagate it there and that would > have to be dealt with on case-by-case basis. But mountpoint is needed for > other stuff like security checks these days as well so we should have it > available in principle. > I agree that propagating the path to fsnotify seem like the right thing to do. fsnotify_inoderemove() is an example (the only one I know of) where path is not available (when called down from from dput()), but frankly, I can't think of any use cases that really needs to make use of the FS_DELETE_SELF event in that case. d_delete() which also calls fsnotify_inoderemove() already calls fsnotify_nameremove() hook with the exact same dentry, so the FS_DELETE_SELF event can be generated by that hook as well as the FS_DELETE event.
