> > Btw, may_open() doesn't do mnt_want_write() around the truncation if
> > file is opened with O_TRUNC | O_RDONLY.
>
> What's the path to may_open() in that case? open_namei() should wrap
> all callers other than nfs, and it does:
>
> /* O_TRUNC implies we need access checks for write pe
On Wed, 2007-09-26 at 19:50 +0200, Miklos Szeredi wrote:
> Maybe. Can we do the mnt_want_write() from __dentry_open(), instead
> of may_open()? That would be a lot cleaner.
I'll explore that. It may make very good sense.
> Btw, may_open() doesn't do mnt_want_write() around the truncation if
>
> On Wed, 2007-09-26 at 10:38 +0200, Miklos Szeredi wrote:
> > In __dentry_open() there's still a few places where fput() won't be
> > called, notably when ->open fails, which is what I'm triggering I
> > think.
> >
> > Also even more horrible things can happen because of the
> > nd->intent.open.f
On Wed, 2007-09-26 at 10:38 +0200, Miklos Szeredi wrote:
> In __dentry_open() there's still a few places where fput() won't be
> called, notably when ->open fails, which is what I'm triggering I
> think.
>
> Also even more horrible things can happen because of the
> nd->intent.open.file thing. Fo
On Wed, 2007-09-26 at 10:38 +0200, Miklos Szeredi wrote:
> > On Wed, 2007-09-26 at 01:14 +0200, Miklos Szeredi wrote:
> > > I get this at umount, if there was a failed open():
> > >
> > > WARNING: at fs/namespace.c:586 __mntput()
> > >
> > > I think the problem is that may_open() calls mnt_want_
On Wed, Sep 26, 2007 at 10:38:22AM +0200, Miklos Szeredi wrote:
> 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_ope
> On Wed, 2007-09-26 at 01:14 +0200, Miklos Szeredi wrote:
> > I get this at umount, if there was a failed open():
> >
> > WARNING: at fs/namespace.c:586 __mntput()
> >
> > I think the problem is that may_open() calls mnt_want_write(), but if
> > open doesn't succeed, mnt_drop_write() will not be
On Wed, 2007-09-26 at 01:14 +0200, Miklos Szeredi wrote:
> I get this at umount, if there was a failed open():
>
> WARNING: at fs/namespace.c:586 __mntput()
>
> I think the problem is that may_open() calls mnt_want_write(), but if
> open doesn't succeed, mnt_drop_write() will not be called.
Does
On Wed, 2007-09-26 at 01:14 +0200, Miklos Szeredi wrote:
> I get this at umount, if there was a failed open():
>
> WARNING: at fs/namespace.c:586 __mntput()
>
> I think the problem is that may_open() calls mnt_want_write(), but if
> open doesn't succeed, mnt_drop_write() will not be called.
I se
I get this at umount, if there was a failed open():
WARNING: at fs/namespace.c:586 __mntput()
I think the problem is that may_open() calls mnt_want_write(), but if
open doesn't succeed, mnt_drop_write() will not be called.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-
10 matches
Mail list logo