Re: [PATCH 02/11] 9p: fix dentry leak in v9fs_vfs_atomic_open_dotl()

[Miklos Szeredi]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/