Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751565AbdCSKq0 (ORCPT ); Sun, 19 Mar 2017 06:46:26 -0400 Received: from 1.multihost.cz ([88.86.107.244]:59562 "EHLO multihost.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751301AbdCSKqX (ORCPT ); Sun, 19 Mar 2017 06:46:23 -0400 Date: Sun, 19 Mar 2017 11:37:39 +0100 From: Filip =?utf-8?B?xaB0xJtkcm9uc2vDvQ==?= To: Jan Kara Cc: Amir Goldstein , linux-fsdevel , linux-kernel , Alexander Viro , Marko Rauhamaa Subject: Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes Message-ID: <20170319103739.aavrnwtbh5qs7f5t@rgvaio> References: <20170319101943.GA1844@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170319101943.GA1844@quack2.suse.cz> User-Agent: NeoMutt/20170128 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 875 Lines: 19 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. 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 Filip