On Wed, Sep 26, 2007 at 10:38:22AM +0200, Miklos Szeredi wrote:
quoted text > Also even more horrible things can happen because of the
> nd->intent.open.file thing. For example if the lookup routine calls
> lookup_instantiate_filp(), and after this, but before may_open() some
> error happens, then release_open_intent() will call fput() on the
> file, which will cause mnt_drop_write() to be called, even though a
> matching mnt_want_write() hasn't yet been called. Ugly, eh?
It's more than horrible. I wouldn't mind using the word utter crap
for it. It's defintively on my todo list to get rid of this junk
again. It managed to get in without proper review unfortunately.
quoted text >
> > I'm also thinking that we should change the open_namei*
> > functions to simply return 'struct file *'. Those are the only users
> > other than NFS, and forcing the return of a file like that will force
> > users to do the fput() on it if they don't want it any more. We'd just
> > need to make sure no new may_open() users pop up. Any thoughts on that?
>
> Yeah, something needs to be done with open, because currently it's way
> too convoluted.
I have some changes for open_namei pending and I'll see if incorporating
this makes sense.
-
unsubscribe notice To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Messages in current thread:
Re: missing mnt_drop_write() on open error , Christoph Hellwig , (Wed Sep 26, 8:07 am)