Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754449AbdCTLkz (ORCPT ); Mon, 20 Mar 2017 07:40:55 -0400 Received: from mail-ot0-f193.google.com ([74.125.82.193]:34336 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754416AbdCTLkn (ORCPT ); Mon, 20 Mar 2017 07:40:43 -0400 MIME-Version: 1.0 In-Reply-To: <20170319180413.GC1844@quack2.suse.cz> References: <20170319101943.GA1844@quack2.suse.cz> <20170319103739.aavrnwtbh5qs7f5t@rgvaio> <20170319180413.GC1844@quack2.suse.cz> From: Amir Goldstein Date: Mon, 20 Mar 2017 07:40:41 -0400 Message-ID: Subject: Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes To: Jan Kara Cc: =?UTF-8?B?RmlsaXAgxaB0xJtkcm9uc2vDvQ==?= , linux-fsdevel , linux-kernel , Alexander Viro , Marko Rauhamaa Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v2KBevu8015951 Content-Length: 2302 Lines: 47 On Sun, Mar 19, 2017 at 2:04 PM, Jan Kara 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.