public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: missing mnt_drop_write() on open error
Date: Tue, 25 Sep 2007 18:21:09 -0700	[thread overview]
Message-ID: <1190769669.26982.325.camel@localhost> (raw)
In-Reply-To: <E1IaJc0-000541-00@dorka.pomaz.szeredi.hu>

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 this help?  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?

--

The r/o bind mount patches have an error in them:
they unconditionally take a mnt_want_write() on
all may_open() requests for writeable files.  They
mistakenly do not mnt_drop_write() if may_open()
encounters an error.

---

 lxc-dave/fs/namei.c |   39 ++++++++++++++++++++++++++++++---------
 1 file changed, 30 insertions(+), 9 deletions(-)

diff -puN fs/namei.c~drop-write-if-may_open-fails fs/namei.c
--- lxc/fs/namei.c~drop-write-if-may_open-fails	2007-09-25 18:16:59.000000000 -0700
+++ lxc-dave/fs/namei.c	2007-09-25 18:16:59.000000000 -0700
@@ -1594,11 +1594,23 @@ int vfs_create(struct inode *dir, struct
 	return error;
 }
 
+/*
+ * If you call this with FMODE_WRITE set in flag,
+ * and get a successful return, you will have
+ * acquired a write on nd->mnt.
+ *
+ * Basically, if you use this function, you either
+ * need to fix up that write count manually, or just
+ * return a 'struct file' from your function.  When
+ * you __fput() that 'struct file' it will get fixed
+ * up automatically.
+ */
 int may_open(struct nameidata *nd, int acc_mode, int flag)
 {
 	struct dentry *dentry = nd->dentry;
 	struct inode *inode = dentry->d_inode;
 	int error;
+	int took_mnt_write = 0;
 
 	if (!inode)
 		return -ENOENT;
@@ -1624,42 +1636,48 @@ int may_open(struct nameidata *nd, int a
 	} else if (flag & FMODE_WRITE) {
 		/*
 		 * effectively: !special_file()
-		 * balanced by __fput()
+		 * Balanced by __fput() and
+		 * released on error at the end
+		 * of this function.
 		 */
 		error = mnt_want_write(nd->mnt);
 		if (error)
 			return error;
+		took_mnt_write = 1;
 	}
 
 	error = vfs_permission(nd, acc_mode);
 	if (error)
-		return error;
+		goto out_err;
 	/*
 	 * An append-only file must be opened in append mode for writing.
 	 */
 	if (IS_APPEND(inode)) {
+		error = -EPERM;
 		if  ((flag & FMODE_WRITE) && !(flag & O_APPEND))
-			return -EPERM;
+			goto out_err;
+		error = -EPERM;
 		if (flag & O_TRUNC)
-			return -EPERM;
+			goto out_err;
 	}
 
 	/* O_NOATIME can only be set by the owner or superuser */
+	error = -EPERM;
 	if (flag & O_NOATIME)
 		if (!is_owner_or_cap(inode))
-			return -EPERM;
+			goto out_err;
 
 	/*
 	 * Ensure there are no outstanding leases on the file.
 	 */
 	error = break_lease(inode, flag);
 	if (error)
-		return error;
+		goto out_err;
 
 	if (flag & O_TRUNC) {
 		error = get_write_access(inode);
 		if (error)
-			return error;
+			goto out_err;
 
 		/*
 		 * Refuse to truncate files with mandatory locks held on them.
@@ -1672,12 +1690,15 @@ int may_open(struct nameidata *nd, int a
 		}
 		put_write_access(inode);
 		if (error)
-			return error;
+			goto out_err;
 	} else
 		if (flag & FMODE_WRITE)
 			DQUOT_INIT(inode);
 
-	return 0;
+out_err:
+	if (error && took_mnt_write)
+		mnt_drop_write(nd->mnt);
+	return error;
 }
 
 static int open_namei_create(struct nameidata *nd, struct path *path,

-- Dave


  parent reply	other threads:[~2007-09-26  1:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-25 23:14 missing mnt_drop_write() on open error Miklos Szeredi
2007-09-25 23:24 ` Dave Hansen
2007-09-26  1:21 ` Dave Hansen [this message]
2007-09-26  8:38   ` Miklos Szeredi
2007-09-26 15:07     ` Christoph Hellwig
2007-09-26 16:14     ` Dave Hansen
2007-09-26 16:19     ` Dave Hansen
2007-09-26 17:50       ` Miklos Szeredi
2007-09-26 18:08         ` Dave Hansen
2007-09-26 18:54           ` Miklos Szeredi

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=1190769669.26982.325.camel@localhost \
    --to=haveblue@us.ibm.com \
    --cc=akpm@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox