Messages in this thread | | | Date | Wed, 18 Sep 2013 10:55:09 +0200 | Subject | Re: [PATCH 02/11] 9p: fix dentry leak in v9fs_vfs_atomic_open_dotl() | From | Miklos Szeredi <> |
| |
On Tue, Sep 17, 2013 at 11:23 PM, Al Viro <viro@zeniv.linux.org.uk> 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@zeniv.linux.org.uk> 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
| |