From: Dave Hansen <haveblue@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-kernel@vger.kernel.org, hch@infradead.org
Subject: Re: [RFC][PATCH 2/7] get mount write in __dentry_open()
Date: Thu, 11 Oct 2007 11:16:56 -0700 [thread overview]
Message-ID: <1192126616.31114.63.camel@localhost> (raw)
In-Reply-To: <E1IfzeX-0007qp-00@dorka.pomaz.szeredi.hu>
On Thu, 2007-10-11 at 17:08 +0200, Miklos Szeredi wrote:
> > diff -puN fs/namei.c~get-write-in-__dentry_open fs/namei.c
> > --- lxc/fs/namei.c~get-write-in-__dentry_open 2007-10-03 14:44:52.000000000 -0700
> > +++ lxc-dave/fs/namei.c 2007-10-04 18:02:48.000000000 -0700
> > @@ -1621,14 +1621,6 @@ int may_open(struct nameidata *nd, int a
> > return -EACCES;
> >
> > flag &= ~O_TRUNC;
> > - } else if (flag & FMODE_WRITE) {
> > - /*
> > - * effectively: !special_file()
> > - * balanced by __fput()
> > - */
> > - error = mnt_want_write(nd->mnt);
> > - if (error)
> > - return error;
> > }
>
> Maybe readonly should still be checked here, so that the order of
> error checking doesn't change. If racing with a read-only remount the
> order is irrelevant anyway. Something like this?
>
> } else if (flag & FMODE_WRITE && __mnt_is_readonly(nd->mnt)) {
> return -EROFS
> }
I think that would be a bug if anything actually managed to trip that
code. all of the may_open() calls should have been covered by the
__dentry_open() mnt writer.
> > error = vfs_permission(nd, acc_mode);
> > @@ -1778,11 +1770,7 @@ do_last:
> >
> > /* Negative dentry, just create the file */
> > if (!path.dentry->d_inode) {
> > - error = mnt_want_write(nd->mnt);
> > - if (error)
> > - goto exit_mutex_unlock;
> > error = open_namei_create(nd, &path, flag, mode);
> > - mnt_drop_write(nd->mnt);
>
> This is still needed, isn't it?
Yes, it is. I'll add a big fat comment this time about why we need it.
> And they should be added around do_truncate() as well, since you
> remove the protection from may_open().
>
> This one introduces an interesting race between ro-remount and
> open(O_TRUNC), where the truncate can succeed but the open fail with
> EROFS. Is that a problem?
You're right, this does introduce that race, and it is relatively hard
to fix properly. But, the 'return a filp' patch makes it easy to fix.
I've put a temporary kludge in the updated version of this patch, and
fixed it properly in that later patch.
> > cleanup_all:
> > fops_put(f->f_op);
> > - if (f->f_mode & FMODE_WRITE)
> > + if (f->f_mode & FMODE_WRITE) {
> > put_write_access(inode);
> > + mnt_drop_write(mnt);
>
> Shouldn't this be conditional on !special_file()?
It certainly should.
-- Dave
next prev parent reply other threads:[~2007-10-11 18:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-10 16:34 [RFC][PATCH 1/7] init_file(): only take writes on normal files Dave Hansen
2007-10-10 16:34 ` [RFC][PATCH 2/7] get mount write in __dentry_open() Dave Hansen
2007-10-11 15:08 ` Miklos Szeredi
2007-10-11 18:16 ` Dave Hansen [this message]
2007-10-11 18:31 ` Miklos Szeredi
2007-10-11 19:24 ` Dave Hansen
2007-10-10 16:34 ` [RFC][PATCH 3/7] do namei_flags calculation inside open_namei() Dave Hansen
2007-10-10 16:34 ` [RFC][PATCH 4/7] make open_namei() return a filp Dave Hansen
2007-10-11 15:24 ` Miklos Szeredi
2007-10-10 16:34 ` [RFC][PATCH 5/7] kill do_filp_open() Dave Hansen
2007-10-10 16:34 ` [RFC][PATCH 6/7] kill filp_open() Dave Hansen
2007-10-10 16:34 ` [RFC][PATCH 7/7] keep track of mnt_writer state of struct file Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1192126616.31114.63.camel@localhost \
--to=haveblue@us.ibm.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.