All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dhaval Giani <dhaval@linux.vnet.ibm.com>
To: menage@google.com
Cc: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Balbir Singh <balbir@in.ibm.com>,
	svaidy@linux.vnet.ibm.com, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, bharata@linux.vnet.ibm.com
Subject: [PATCH] Fix for bad lock balance in Containers
Date: Tue, 26 Jun 2007 10:30:11 +0530	[thread overview]
Message-ID: <20070626050011.GA12584@linux.vnet.ibm.com> (raw)

Hi,

I have been going through the containers code and trying it out. I tried
mounting the same hierarchy at two different points and I got a bad
locking balance warning.

=====================================
[ BUG: bad unlock balance detected! ]
-------------------------------------
mount/4467 is trying to release lock (&type->s_umount_key) at:
[<c017de3b>] vfs_kern_mount+0x5b/0x70
but there are no more locks to release!

other info that might help us debug this:
no locks held by mount/4467.

stack backtrace:
 [<c0105b9f>] show_trace_log_lvl+0x19/0x2e
 [<c0105bc6>] show_trace+0x12/0x14
 [<c0105cb1>] dump_stack+0x14/0x16
 [<c0142c1a>] print_unlock_inbalance_bug+0xcc/0xd6
 [<c0142c93>] check_unlock+0x6f/0x75
 [<c0142ee0>] __lock_release+0x1e/0x51
 [<c014312c>] lock_release+0x4c/0x64
 [<c013bd9d>] up_write+0x16/0x2b
 [<c017de3b>] vfs_kern_mount+0x5b/0x70
 [<c018fae7>] do_new_mount+0x85/0xe6
 [<c019013f>] do_mount+0x185/0x199
 [<c01903ab>] sys_mount+0x71/0xa6
 [<c0104d6a>] sysenter_past_esp+0x5f/0x99
 =======================

Going through the code, I realised this is because when the container is
already mounted at one point, when being remounted, it just does a
simple_set_mnt which does not update s_umount which causes the warning
to come. This also cause umount to hang the second time.

The correct method would be allocate the superblock using sget (or a
variant) which would call grab_super correctly and set these locks.
Seeing the code which is there, some part of grab_super is already done
in container_get_sb where the root->sb->s_active is updated. So I have
called down_write there as well to get the locking balance. However I
believe that this is not the correct approach.

There are a few questions I had with respect to the current code,

Why is the increment of s_active dependent on the return value of
simple_set_mnt? All the other functions which I have seen (fs ones),
grab_super (which increments s_active) is called followed by a
simple_set_mnt.

What should be the correct approach to get the locking balance? As far
as I can see, the correct method would be to call sget which would then
correctly handle everything. But that would require a test function. I
saw functionality similar to a test function in the beginning of
container_get_sb(). Should that be seperated and put in a seperate test
function so that sget can be called?

Another possible approach would be to call grab_super directly (since we
know the test function is going to return true), but this cannot be done
since grab_super is static right now. Or maybe we could duplicate
grab_super's functionality.

In the meantime a temporary fix.

Thanks and regards
Dhaval

Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>


--- linux-2.6.22-rc4/kernel/container.c	2007-06-13 15:38:32.000000000 +0530
+++ old/kernel/container.c	2007-06-25 00:55:03.000000000 +0530
@@ -995,6 +995,7 @@ static int container_get_sb(struct file_
 		BUG_ON(ret);
 	} else {
 		/* Reuse the existing superblock */
+		down_write(&(root->sb->umount));
 		ret = simple_set_mnt(mnt, root->sb);
 		if (!ret)
 			atomic_inc(&root->sb->s_active);

             reply	other threads:[~2007-06-26  5:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-26  5:00 Dhaval Giani [this message]
2007-06-27  6:38 ` [PATCH] Fix for bad lock balance in Containers Bharata B Rao
2007-06-27  7:34 ` Dhaval Giani
2007-06-28 23:09 ` Paul Menage

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=20070626050011.GA12584@linux.vnet.ibm.com \
    --to=dhaval@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@in.ibm.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=vatsa@linux.vnet.ibm.com \
    /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.