lkml.org 
[lkml]   [2013]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 02/11] 9p: fix dentry leak in v9fs_vfs_atomic_open_dotl()
From
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


\
 
 \ /
  Last update: 2013-09-18 11:01    [W:0.063 / U:1.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site