Re: [RFC 1/2] fanotify: new event FAN_MODIFY_DIR

[Jan Kara]

On Wed 15-03-17 16:34:11, Amir Goldstein wrote:
> On Wed, Mar 15, 2017 at 4:05 PM, Jan Kara <jack@xxxxxxx> wrote:
> >> So the string fields in my proposal are optional.
> >> userspace opts-in to get them by specifying the  FAN_EVENT_INFO_NAME flag:
> >>
> >>     fanotify_init(FAN_CLOEXEC | FAN_CLASS_NOTIF |
> >>                        FAN_EVENT_INFO_PARENT | FAN_EVENT_INFO_NAME,
> >>
> >> If you don't specify FAN_EVENT_INFO_NAME, you can get filename events
> >> FAN_MOVE|FAN_CREATE|FAN_DELETE without the name.
> >
> > So when thinking about this again, I'm again concerned that the names need
> > not tell userspace what it thinks. I know we already discussed this but
> > in our last discussion I think I forgot to point out that inotify directory
> > events (and fanotify would be the same AFAICT) may come out of order compared
> > to real filesystem changes. E.g. sequence:
> >
> > Task 1          Task 2
> >
> > mv a b
> >                 mv b c
> >
> > may come out of inotify as:
> >
> > IN_MOVED_FROM "b" COOKIE 1
> > IN_MOVED_TO   "c" COOKIE 1
> > IN_MOVED_FROM "a" COOKIE 2
> > IN_MOVED_TO   "b" COOKIE 2
> >
> 
> Really? How come?
> 
> fsnotify_move() inside vfs_rename() is serialized with lock_rename()

Sorry, I got confused by the unlocking in vfs_rename() however that unlocks
only the moved file / directory but not the directory in which the rename
is happening. Taking my objection back.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR