[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130917212359.GJ13318@ZenIV.linux.org.uk>
Date: Tue, 17 Sep 2013 22:23:59 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
Kernel Mailing List <linux-kernel@...r.kernel.org>,
"mszeredi@...e.cz" <mszeredi@...e.cz>,
Eric Van Hensbergen <ericvh@...il.com>,
"M. Mohan Kumar" <mohan@...ibm.com>, stable@...r.kernel.org
Subject: Re: [PATCH 02/11] 9p: fix dentry leak in v9fs_vfs_atomic_open_dotl()
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@...iv.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.
Anyway, I've pushed what I think is a sane fix. Please, review and test -
I don't have a setup for testing fsnotify on fuse.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists