All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 2/5] fsnotify: annotate filename events
Date: Tue, 20 Nov 2018 12:59:01 +0100	[thread overview]
Message-ID: <20181120115901.GH8842@quack2.suse.cz> (raw)
In-Reply-To: <20181114174344.17530-3-amir73il@gmail.com>

On Wed 14-11-18 19:43:41, Amir Goldstein wrote:
> Filename events are referring to events that modify directory entries,
> such as create,delete,rename. Those events should always be reported
> on a watched directory, regardless if FS_EVENT_ON_CHILD is set
> on the watch mask.

OK, I find 'directory modification events' clearer than 'filename events'.
But I can live with your name since I don't really have a better
alternative :). Just please define these events in terms of all FS_<foo>
events that are involved so that everyone is on the same page which events
you mean.

> fsnotify_nameremove() and fsnotify_move() were modified to no longer
> set the FS_EVENT_ON_CHILD event bit. This is a semantic change to
> align with the filename event definition. It has no effect on any
> existing backend, because dnotify and inotify always requets the
> child events and fanotify does not get the delete,rename events.

You keep forgetting about audit ;) But in this case it is fine as it always
sets FS_EVENT_ON_CHILD as well.

> The fsnotify_filename() helper is used to report all the filename
> events. It gets a reference on parent dentry and passes it as the
> data for the event along with the filename.
> 
> fsnotify_filename() is different from fsnotify_parent().
> fsnotify_parent() is intended to report any events that happened on
> child inodes when FS_EVENT_ON_CHILD is requested.
> fsnotify_filename() is intended to report only filename events,
> such as create,mkdir,link. Those events must always be reported
> on a watched directory, regardless if FS_EVENT_ON_CHILD was requested.
> 
> fsnotify_d_name() is a helper for the common case where the
> filename to pass is dentry->d_name.name.
> 
> It is safe to use these helpers with negative or not instantiated
> dentries, such as the case with fsnotify_link() and
> fsnotify_nameremove().
> 
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>  include/linux/fsnotify.h | 40 +++++++++++++++++++++++++++++++---------
>  1 file changed, 31 insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
> index 9dadc0bcd7a9..d00ec5838d6e 100644
> --- a/include/linux/fsnotify.h
> +++ b/include/linux/fsnotify.h
> @@ -17,8 +17,31 @@
>  #include <linux/slab.h>
>  #include <linux/bug.h>
>  
> +/*
> + * Notify this parent about a filename event (create,delete,rename).
> + * Unlike fsnotify_parent(), the event will be reported regardless of the
> + * FS_EVENT_ON_CHILD mask on the parent inode
> + */

How about specifying this as 'Notify directory 'parent' about a change of
some of its directory entries'? That way you avoid using 'filename' event
in the description which is not defined.

> +static inline int fsnotify_filename(struct dentry *parent, __u32 mask,
> +				    const unsigned char *file_name, u32 cookie)

And how about calling the function fsnotify_dir_change()?

> +{
> +	return fsnotify(d_inode(parent), mask, parent, FSNOTIFY_EVENT_DENTRY,
> +			file_name, cookie);
> +}
> +
> +/*
> + * Call fsnotify_filename() with parent and d_name of this dentry.
> + * Safe to call with negative dentry, e.g. from fsnotify_nameremove()
> + */
> +static inline int fsnotify_d_name(struct dentry *dentry, __u32 mask)

Maybe call this fsnotify_dir_dentry_change()?

> +{
> +	return fsnotify_filename(dentry->d_parent, mask,
> +				 dentry->d_name.name, 0);
> +}
> +
>  /* Notify this dentry's parent about a child's events. */
> -static inline int fsnotify_parent(const struct path *path, struct dentry *dentry, __u32 mask)
> +static inline int fsnotify_parent(const struct path *path,
> +				  struct dentry *dentry, __u32 mask)
>  {
>  	if (!dentry)
>  		dentry = path->dentry;
> @@ -85,8 +108,8 @@ static inline void fsnotify_move(struct inode *old_dir, struct inode *new_dir,
>  {
>  	struct inode *source = moved->d_inode;
>  	u32 fs_cookie = fsnotify_get_cookie();
> -	__u32 old_dir_mask = (FS_EVENT_ON_CHILD | FS_MOVED_FROM);
> -	__u32 new_dir_mask = (FS_EVENT_ON_CHILD | FS_MOVED_TO);
> +	__u32 old_dir_mask = FS_MOVED_FROM;
> +	__u32 new_dir_mask = FS_MOVED_TO;

You can just inline these two masks now. There's no point for the variable
anymore.

> @@ -99,8 +122,7 @@ static inline void fsnotify_move(struct inode *old_dir, struct inode *new_dir,
>  
>  	fsnotify(old_dir, old_dir_mask, source, FSNOTIFY_EVENT_INODE, old_name,
>  		 fs_cookie);
> -	fsnotify(new_dir, new_dir_mask, moved, FSNOTIFY_EVENT_DENTRY, new_name,
> -		 fs_cookie);
> +	fsnotify_filename(moved->d_parent, new_dir_mask, new_name, fs_cookie);

The same comment as for the patch 1 here. You should justify that
moved->d_parent is actually the same as new_dir and the dentry cannot
change under us. The same holds for all the calls of fsnotify_d_name()
where the directory inode originally passed in gets replaced with
d_inode(dentry->d_parent).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2018-11-20 22:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-14 17:43 [PATCH v2 0/5] fsnotify prep work for fanotify dentry events Amir Goldstein
2018-11-14 17:43 ` [PATCH v2 1/5] fsnotify: pass dentry instead of inode when available Amir Goldstein
2018-11-20 11:32   ` Jan Kara
2018-11-20 14:36     ` Amir Goldstein
2018-11-21 12:51       ` Jan Kara
2018-11-21 16:13         ` Amir Goldstein
2018-11-22  9:52           ` Jan Kara
2018-11-22 12:36             ` Amir Goldstein
2018-11-22 13:26               ` Jan Kara
2018-11-22 15:18                 ` Amir Goldstein
2018-11-22 19:42                   ` Amir Goldstein
2018-11-23 12:56                     ` Jan Kara
2018-11-23 13:42                       ` Amir Goldstein
2018-11-23 12:52                   ` Btrfs and fanotify filesystem watches Jan Kara
2018-11-23 13:34                     ` Amir Goldstein
2018-11-23 17:53                       ` Amir Goldstein
2018-11-27  8:35                         ` Jan Kara
2018-11-14 17:43 ` [PATCH v2 2/5] fsnotify: annotate filename events Amir Goldstein
2018-11-20 11:59   ` Jan Kara [this message]
2018-11-20 14:58     ` Amir Goldstein
2018-11-21 13:18       ` Jan Kara
2018-11-21 15:40         ` Amir Goldstein
2018-11-22  7:45           ` Amir Goldstein
2018-11-22  9:33             ` Jan Kara
2018-11-22  8:40     ` Amir Goldstein
2018-11-14 17:43 ` [PATCH v2 3/5] fsnotify: simplify API for " Amir Goldstein
2018-11-14 17:43 ` [PATCH v2 4/5] fsnotify: make MOVED_FROM a dentry event Amir Goldstein
2018-11-20 12:45   ` Jan Kara
2018-11-14 17:43 ` [PATCH v2 5/5] fsnotify: send event type FSNOTIFY_EVENT_DENTRY to super block mark Amir Goldstein

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=20181120115901.GH8842@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.