From: "Filip Štědronský" <r.lkml@regnarg.cz>
To: Jan Kara <jack@suse.cz>
Cc: Amir Goldstein <amir73il@gmail.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Marko Rauhamaa <marko.rauhamaa@f-secure.com>
Subject: Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes
Date: Sun, 19 Mar 2017 11:37:39 +0100 [thread overview]
Message-ID: <20170319103739.aavrnwtbh5qs7f5t@rgvaio> (raw)
In-Reply-To: <20170319101943.GA1844@quack2.suse.cz>
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
next prev parent reply other threads:[~2017-03-19 10:46 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-13 23:02 [RFC 1/2] fanotify: new event FAN_MODIFY_DIR Filip Štědronský
2017-03-13 23:03 ` [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes Filip Štědronský
2017-03-14 11:18 ` Amir Goldstein
2017-03-14 14:58 ` Filip Štědronský
2017-03-14 15:35 ` Amir Goldstein
2017-03-15 8:19 ` Marko Rauhamaa
2017-03-15 13:39 ` Jan Kara
2017-03-15 14:18 ` Marko Rauhamaa
2017-03-15 14:44 ` Amir Goldstein
2017-03-19 10:19 ` Jan Kara
2017-03-19 10:37 ` Filip Štědronský [this message]
2017-03-19 18:04 ` Jan Kara
2017-03-20 11:40 ` Amir Goldstein
2017-03-20 11:52 ` Filip Štědronský
2017-03-21 15:38 ` J. Bruce Fields
2017-03-21 16:41 ` Jan Kara
2017-03-21 17:45 ` J. Bruce Fields
2017-03-13 23:16 ` [RFC 1/2] fanotify: new event FAN_MODIFY_DIR Filip Štědronský
2017-03-14 10:40 ` Amir Goldstein
2017-03-14 13:46 ` Filip Štědronský
2017-03-14 15:07 ` Amir Goldstein
2017-03-20 12:10 ` Amir Goldstein
2017-03-14 10:11 ` Amir Goldstein
2017-03-14 12:41 ` Filip Štědronský
2017-03-14 13:55 ` Amir Goldstein
2017-03-14 14:48 ` Filip Štědronský
2017-03-14 22:30 ` Amir Goldstein
2017-03-15 14:05 ` Jan Kara
2017-03-15 14:34 ` Amir Goldstein
2017-03-16 10:38 ` Jan Kara
2017-03-15 4:52 ` Michael Kerrisk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170319103739.aavrnwtbh5qs7f5t@rgvaio \
--to=r.lkml@regnarg.cz \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marko.rauhamaa@f-secure.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®