All of lore.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 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.