> > > How do you propose to change fsnotify hooks in vfs_create()?
> >
> > So either pass 'mnt' to vfs_create() - as we discussed, this may be
> > actually acceptable these days due to idmapped mounts work - and generate
> > all events there, or make vfs_create() not generate any fsnotify events and
> > create new vfs_create_notify() which will take the 'mnt' and generate
> > events. Either is fine with me and more consistent than what you currently
> > propose. Thoughts?
> >
>
> Jan,
>
> I started to go down the vfs_create_notify() path and I guess it's looking
> not too bad (?). Pushed WIP to branch fsnotify_path_hooks-wip.
>
> I hit another bump though. By getting fsnotify_{unlink,rmdir}() outside of the
> vfs helpers, we break the rule:
>
> /* Expected to be called before d_delete() */
> WARN_ON_ONCE(d_is_negative(dentry));
>
> I'm not sure how to solve this without passing mnt into the vfs helpers.
>
Nevermind, I figured it out.
Created a helper fsnotify_delete() that allows a negative dentry
and takes a separate victim inode arg.
fsnotify_{unlink,rmdir}_notify() take care of holding the reference to
the victim inode.
I also realized that passing mnt to fsnotify() as path data arg
is limiting and over complicating, so passing it as a separate arg.
Packed all args to fsnotify() in struct fsnotify_event_info.
Pushed what I have so far to fsnotify_path_hooks-wip.
Thanks,
Amir.
