On Thu, Jan 3, 2019 at 5:41 PM Jan Kara <jack@xxxxxxx> wrote:
>
> On Sun 02-12-18 13:38:12, Amir Goldstein wrote:
> > "dirent" 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.
> >
> > 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 "dirent" event definition. It has no effect on any
> > existing backend, because dnotify, inotify and audit always requets the
> > child events and fanotify does not get the delete,rename events.
> >
> > The fsnotify_dirent() helper is used instead of fsnotify_parent() to
> > report a dirent event to dentry->d_parent without FS_EVENT_ON_CHILD
> > and regardless if parent has the FS_EVENT_ON_CHILD bit set.
> >
> > ALL_FSNOTIFY_DIRENT_EVENTS defines all the dirent event types and
> > those event types have been extracted out of FS_EVENTS_POSS_ON_CHILD.
> >
> > That means for a directory with an inotify watch and only dirent
> > events in the mask (i.e. create,delete,move), all children dentries
> > will no longer have the DCACHE_FSNOTIFY_PARENT_WATCHED flag set.
> > This will allow all events that happen on children to be optimized
> > away in __fsnotify_parent() without the need to dereference
> > child->d_parent->d_inode->i_fsnotify_mask.
> >
> > Since the dirent events are never repoted via __fsnotify_parent(),
> > this results in no change of logic, but only an optimization.
> >
> > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
> > ---
> > include/linux/fsnotify.h | 42 +++++++++++++++++++++++++-------
> > include/linux/fsnotify_backend.h | 36 +++++++++++++++------------
> > 2 files changed, 54 insertions(+), 24 deletions(-)
> >
> > diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
> > index 2ccb08cb5d6a..8de8f390cce2 100644
> > --- a/include/linux/fsnotify.h
> > +++ b/include/linux/fsnotify.h
> > @@ -17,8 +17,35 @@
> > #include <linux/slab.h>
> > #include <linux/bug.h>
> >
> > +/*
> > + * Notify this @dir inode about a change in the directory entry @dentry.
> > + *
> > + * Unlike fsnotify_parent(), the event will be reported regardless of the
> > + * FS_EVENT_ON_CHILD mask on the parent inode.
> > + *
> > + * When called with NULL @dir (from fsnotify_nameremove()), the dentry parent
> > + * inode is used as the inode to report the event to.
> > + */
> > +static inline int fsnotify_dirent(struct inode *dir, struct dentry *dentry,
> > + __u32 mask)
> > +{
> > + if (!dir)
> > + dir = d_inode(dentry->d_parent);
>
> Just a small nit: This !dir handling is only used for
> fsnotify_nameremove(). So why not move that d_parent logic to that single
> call site? That would make the function easier to argue about.
>
Yeh, I did that it Errata patch 16/15 (already squashed on my dev branch):
https://marc.info/?l=linux-fsdevel&m=154410829914931&w=2
> Otherwise I like the patch.
>
> Honza
>
> > +
> > + /*
> > + * This helper assumes d_parent and d_name are stable. It must be true
> > + * when called from fsnotify_create()/fsnotify_mkdir(). Less sure about
> > + * all callers that get here from d_delete() => fsnotify_nameremove().
> > + */
> > + WARN_ON(!inode_is_locked(dir));
In your review of v3 you wrote:
https://marc.info/?l=linux-fsdevel&m=154340994815488&w=2
"generally directory i_rwsem is held when unlinking and so dentry name cannot
change but then it would be good to assert that? Who knows what some weird
fs is doing..."
So I went and did the research. The result is in said 16/15 Errata patch.
Not sure you will like it though...
Thanks,
Amir.
