On Tue, Sep 17, 2013 at 11:23 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Tue, Sep 17, 2013 at 05:36:49PM +0200, Miklos Szeredi wrote: >> On Tue, Sep 17, 2013 at 1:44 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >> > On Tue, Sep 17, 2013 at 12:16:56PM +0200, Miklos Szeredi wrote: >> > >> >> Just one. This needs to be removed, since this condition is now >> >> explicitly allowed and later checked for: >> >> >> >> if (WARN_ON(excl && !(*opened & FILE_CREATED))) >> >> *opened |= FILE_CREATED; >> > >> > D'oh... Fixed and pushed. >> >> Okay, but moving the fsnotify_create() to after the no-open section >> is wrong, I think, It's needed for the case of ->atomic_open() doing >> lookup/create/no_open too. > > What a mess... It's actually even uglier than that - which dentry should > we pass to fsnotify_create() in case where finish_no_open() has been given > a non-NULL dentry other than one we had passed to ->atomic_open()? I think > that version in mainline is actually broken in that respect as far as fuse > is concerned, not that anybody sane could expect ...notify to work on fuse. Yeah, your version is definitely nicer. The correctness of the old version could be argued thus: if FILE_CREATED was set, then the file didn't exist before, so there's no sense in reusing or allocating another dentry. But yes, the API allows it. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html