public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitriy Monakhov <dmonakhov@sw.ru>
To: Dmitriy Monakhov <dmonakhov@sw.ru>
Cc: linux-kernel@vger.kernel.org, devel@openvz.org
Subject: Re: [PATCH] ecryptfs ecryptfs_read_super path_lookup errh fix
Date: Mon, 19 Feb 2007 22:11:59 +0300	[thread overview]
Message-ID: <87ejom55ds.fsf@sw.ru> (raw)
In-Reply-To: <87bqjqp2bt.fsf@sw.ru> (Dmitriy Monakhov's message of "Mon, 19 Feb 2007 18:57:42 +0300")

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

Dmitriy Monakhov <dmonakhov@sw.ru> writes:

> if path_lookup() return non zero code we don't have to worry about 'nd' 
> parameter, but ecryptfs_read_super does path_release(&nd) after path_lookup
> has failed, and dentry counter becomes negative :) , this result in folowing BUG
>
> ecryptfs_read_super: path_lookup() failed
> BUG: Dentry f3f074c4{i=0,n=enc_dir} still in use (-1) [unmount of ext3 dm-5]
> <<<<<<<<<<<<<<<<<<<<<counter is negative here   ^^^^^^
> ------------[ cut here ]------------
> kernel BUG at fs/dcache.c:654!
>  [<c01063d6>] die+0x11e/0x233
>  [<c042ed50>] do_trap+0x8a/0xa3
>  [<c0106979>] do_invalid_op+0x97/0xa1
>  [<c042eb14>] error_code+0x7c/0x84
>  [<c0183f5f>] shrink_dcache_for_umount+0x2d/0x3a
>  [<c0176166>] generic_shutdown_super+0x18/0xbe
>  [<c017622c>] kill_block_super+0x20/0x32
>  [<c01762ce>] deactivate_super+0x3f/0x51
>  [<c018724d>] mntput_no_expire+0x42/0x6b
>  [<c017a719>] path_release+0x20/0x23
>  [<f886387d>] ecryptfs_get_sb+0x45a/0x4ad [ecryptfs]
>  [<c0176361>] vfs_kern_mount+0x81/0xf1
>  [<c0176419>] do_kern_mount+0x30/0x42
>  [<c018847b>] do_mount+0x601/0x678
>  [<c0188561>] sys_mount+0x6f/0xa9
>  [<c0104f2c>] sysenter_past_esp+0x5d/0x99
>  =======================
> Code: 30 02 00 00 89 44 24 18 8b 45 ec 89 4c 24 14 89 74 24 10 89 7c 24 0c 89 5c 24 04 89 44 24 08 c7 04 24 ee 9d 4f c0 e8 b7 74 fa ff <0f> 0b eb fe 8b 73 30 39 de 75 04 31 f6 eb 03 f0 ff 0e 8d 43 48 
> EIP: [<c01831a7>] shrink_dcache_for_umount_subtree+0x159/0x1fb SS:ESP 0068:f4269c7c
>
> This is easy to reproduce just try to mount ecryptfs to nonexisting lower path
> # mount -tecryptfs private/this_dir_not_exist root -ocipher=aes
This is fun but ecryptfs_read_super() code is more crappy whan it looks at 
first blush.
1) After path_lookup succeed we dot't have any guarantie what it is DIR.
   This must be checked explicitly.
2) path_lookup can't return negative dentry, So inode check is useless.

Following patch is updated version and have to be applied instead of first patch 
Signed-off-by: Dmitriy Monakhov <dmonakhov@openvz.org>
-------------

[-- Attachment #2: diff-mm-ecryptfs-ecryptfs_read_super-fix --]
[-- Type: text/plain, Size: 828 bytes --]

diff --git a/fs/ecryptfs/main.c b/fs/ecryptfs/main.c
index 80044d1..fc4a3a2 100644
--- a/fs/ecryptfs/main.c
+++ b/fs/ecryptfs/main.c
@@ -484,18 +484,12 @@ static int ecryptfs_read_super(struct super_block *sb, const char *dev_name)
 	struct vfsmount *lower_mnt;
 
 	memset(&nd, 0, sizeof(struct nameidata));
-	rc = path_lookup(dev_name, LOOKUP_FOLLOW, &nd);
+	rc = path_lookup(dev_name, LOOKUP_FOLLOW | LOOKUP_DIRECTORY, &nd);
 	if (rc) {
 		ecryptfs_printk(KERN_WARNING, "path_lookup() failed\n");
-		goto out_free;
+		goto out;
 	}
 	lower_root = nd.dentry;
-	if (!lower_root->d_inode) {
-		ecryptfs_printk(KERN_WARNING,
-				"No directory to interpose on\n");
-		rc = -ENOENT;
-		goto out_free;
-	}
 	lower_mnt = nd.mnt;
 	ecryptfs_set_superblock_lower(sb, lower_root->d_sb);
 	sb->s_maxbytes = lower_root->d_sb->s_maxbytes;

      reply	other threads:[~2007-02-19 19:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-19 15:57 [PATCH] ecryptfs ecryptfs_read_super path_lookup errh fix Dmitriy Monakhov
2007-02-19 19:11 ` Dmitriy Monakhov [this message]

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=87ejom55ds.fsf@sw.ru \
    --to=dmonakhov@sw.ru \
    --cc=devel@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    /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