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. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
