linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [2.6.38] Possible deadlock at pivot_root?
@ 2011-03-16  8:54 Tetsuo Handa
  2011-03-17  5:01 ` [2.6.38] Deadlock between rename_lock and vfsmount_lock Tetsuo Handa
  0 siblings, 1 reply; 13+ messages in thread
From: Tetsuo Handa @ 2011-03-16  8:54 UTC (permalink / raw)
  To: linux-fsdevel

I got a freeze (without lockdep warning) with a small out-of-tree patch
applied on 2.6.38. It seems to me that the deadlock occurred when running
pivot_root(). I guess it is spinning at spin_lock() below.

Is below lock dependency safe?

d_path():

  write_seqlock(&rename_lock);
    br_read_lock(vfsmount_lock);
      spin_lock(&dentry->d_lock);

      spin_unlock(&dentry->d_lock);
    br_read_unlock(vfsmount_lock);
  write_sequnlock(&rename_lock);

pivot_root():

  down_write(&namespace_sem);
    mutex_lock(&old.dentry->d_inode->i_mutex);
      br_write_lock(vfsmount_lock);
        spin_lock(&dentry->d_lock);

        spin_unlock(&dentry->d_lock);
      br_write_unlock(vfsmount_lock);
    mutex_unlock(&old.dentry->d_inode->i_mutex);
  up_write(&namespace_sem);

[  384.711037] 8 locks held by make/6110:
[  384.711037]  #0:  (&ccs_ss){.+.+.+}, at: [<c11bc320>] ccs_path_perm+0x0/0x1c0
[  384.711037]  #1:  (rename_lock){+.+...}, at: [<c10e41c9>] __d_path+0x39/0x80
[  384.711037]  #2:  (vfsmount_lock){++++..}, at: [<c10e8500>] vfsmount_lock_local_lock+0x0/0x60
[  384.711037]  #3:  (&serio->lock){-.-...}, at: [<c12ddb68>] serio_interrupt+0x28/0x80
[  384.711037]  #4:  (&(&dev->event_lock)->rlock){-.-...}, at: [<c12e053f>] input_event+0x3f/0x70
[  384.711037]  #5:  (rcu_read_lock){.+.+..}, at: [<c12dfe30>] input_pass_event+0x0/0x1c0
[  384.711037]  #6:  (sysrq_key_table_lock){-.-...}, at: [<c124c348>] __handle_sysrq+0x18/0x110
[  384.711037]  #7:  (tasklist_lock){.?.?..}, at: [<c10701a6>] debug_show_all_locks+0x36/0x1d0
[  384.711037] 

(I think #3 to #7 are caused by pressing sysrq key.)
Complete log is at http://I-love.SAKURA.ne.jp/tmp/dmesg-2.6.38.txt

Regards.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-16  8:54 [2.6.38] Possible deadlock at pivot_root? Tetsuo Handa
@ 2011-03-17  5:01 ` Tetsuo Handa
  2011-03-18 10:59   ` Tetsuo Handa
  0 siblings, 1 reply; 13+ messages in thread
From: Tetsuo Handa @ 2011-03-17  5:01 UTC (permalink / raw)
  To: linux-fsdevel

Tetsuo Handa wrote:
> I got a freeze (without lockdep warning) with a small out-of-tree patch
> applied on 2.6.38. It seems to me that the deadlock occurred when running
> pivot_root(). I guess it is spinning at spin_lock() below.

It seems to me that this is a deadlock between rename_lock and vfsmount_lock.

CPU 0: __d_path()                       CPU 1: pivot_root()
write_seqlock(&rename_lock);            br_write_lock(vfsmount_lock);
br_read_lock(vfsmount_lock);            seq = read_seqbegin(&rename_lock);

__d_path() calls prepend_path() with rename_lock lock held for write.

char *__d_path(const struct path *path, struct path *root,
               char *buf, int buflen)
{
        char *res = buf + buflen;
        int error;

        prepend(&res, &buflen, "\0", 1);
        write_seqlock(&rename_lock);
        error = prepend_path(path, root, &res, &buflen);
        write_sequnlock(&rename_lock);

        if (error)
                return ERR_PTR(error);
        return res;
}

prepend_path() tries to hold vfsmount_lock for read.

static int prepend_path(const struct path *path, struct path *root,
                        char **buffer, int *buflen)
{
        struct dentry *dentry = path->dentry;
        struct vfsmount *vfsmnt = path->mnt;
        bool slash = false;
        int error = 0;

        br_read_lock(vfsmount_lock);
        while (dentry != root->dentry || vfsmnt != root->mnt) {
                struct dentry * parent;

                if (dentry == vfsmnt->mnt_root || IS_ROOT(dentry)) {
                        /* Global root? */
                        if (vfsmnt->mnt_parent == vfsmnt) {
                                goto global_root;
                        }
                        dentry = vfsmnt->mnt_mountpoint;
                        vfsmnt = vfsmnt->mnt_parent;
                        continue;
                }
                parent = dentry->d_parent;
                prefetch(parent);
                spin_lock(&dentry->d_lock);
                error = prepend_name(buffer, buflen, &dentry->d_name);
                spin_unlock(&dentry->d_lock);
                if (!error)
                        error = prepend(buffer, buflen, "/", 1);
                if (error)
                        break;

                slash = true;
                dentry = parent;
        }

out:
        if (!error && !slash)
                error = prepend(buffer, buflen, "/", 1);

        br_read_unlock(vfsmount_lock);
        return error;

global_root:
        /*
         * Filesystems needing to implement special "root names"
         * should do so with ->d_dname()
         */
        if (IS_ROOT(dentry) &&
            (dentry->d_name.len != 1 || dentry->d_name.name[0] != '/')) {
                WARN(1, "Root dentry has weird name <%.*s>\n",
                     (int) dentry->d_name.len, dentry->d_name.name);
        }
        root->mnt = vfsmnt;
        root->dentry = dentry;
        goto out;
}

pivot_root() calls is_subdir() with vfsmount_lock lock held for write.

SYSCALL_DEFINE2(pivot_root, const char __user *, new_root,
                const char __user *, put_old)
{
(...snipped...)
        br_write_lock(vfsmount_lock);
        if (tmp != new.mnt) {
                for (;;) {
                        if (tmp->mnt_parent == tmp)
                                goto out3; /* already mounted on put_old */
                        if (tmp->mnt_parent == new.mnt)
                                break;
                        tmp = tmp->mnt_parent;
                }
                if (!is_subdir(tmp->mnt_mountpoint, new.dentry))
                        goto out3;
        } else if (!is_subdir(old.dentry, new.dentry))
                goto out3;
        detach_mnt(new.mnt, &parent_path);
        detach_mnt(root.mnt, &root_parent);
        /* mount old root on put_old */
        attach_mnt(root.mnt, &old);
        /* mount new_root on / */
        attach_mnt(new.mnt, &root_parent);
        touch_mnt_namespace(current->nsproxy->mnt_ns);
        br_write_unlock(vfsmount_lock);
(...snipped...)
}

is_subdir() tries to hold rename_lock for read.

int is_subdir(struct dentry *new_dentry, struct dentry *old_dentry)
{
        int result;
        unsigned seq;

        if (new_dentry == old_dentry)
                return 1;

        do {
                /* for restarting inner loop in case of seq retry */
                seq = read_seqbegin(&rename_lock);
                /*
                 * Need rcu_readlock to protect against the d_parent trashing
                 * due to d_move
                 */
                rcu_read_lock();
                if (d_ancestor(old_dentry, new_dentry))
                        result = 1;
                else
                        result = 0;
                rcu_read_unlock();
        } while (read_seqretry(&rename_lock, seq));

        return result;
}

is_subdir() tries to hold rename_lock lock, but it is held by __d_path().
prepend_path() tries to hold vfsmount_lock lock but is held by pivot_root().

Regards.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-17  5:01 ` [2.6.38] Deadlock between rename_lock and vfsmount_lock Tetsuo Handa
@ 2011-03-18 10:59   ` Tetsuo Handa
  2011-03-18 11:06     ` Al Viro
  0 siblings, 1 reply; 13+ messages in thread
From: Tetsuo Handa @ 2011-03-18 10:59 UTC (permalink / raw)
  To: npiggin, viro; +Cc: linux-fsdevel

I established steps to reproduce.

On a 2.6.38 kernel built with CONFIG_SMP=y running on an SMP machine, run

  while :; do newns /sbin/pivot_root /proc/ /proc/sys/; done

on one terminal and run

  while :; do /bin/ls -l /proc/*/exe; done

on another terminal. (The "newns" is a program that unshares the mnt namespace
before execve() using CLONE_NEWNS.)

Below patch releases/reacquires vfsmount_lock when rescheduling is required.
---
 fs/dcache.c             |   15 ++++++++++++++-
 fs/namespace.c          |    6 ++++++
 include/linux/sched.h   |    2 ++
 include/linux/seqlock.h |    4 ++++
 4 files changed, 26 insertions(+), 1 deletion(-)

--- linux-2.6.38.orig/include/linux/sched.h
+++ linux-2.6.38/include/linux/sched.h
@@ -1528,6 +1528,8 @@ struct task_struct {
 		unsigned long memsw_bytes; /* uncharged mem+swap usage */
 	} memcg_batch;
 #endif
+	u8 vfsmntlock_held_for_write;
+	u8 retry_vfsmntlock;
 };
 
 /* Future-safe accessor for struct task_struct's cpus_allowed. */
--- linux-2.6.38.orig/include/linux/seqlock.h
+++ linux-2.6.38/include/linux/seqlock.h
@@ -82,6 +82,8 @@ static inline int write_tryseqlock(seqlo
 	return ret;
 }
 
+extern bool need_to_giveup(const seqlock_t *sl);
+
 /* Start of read calculation -- fetch last complete writer token */
 static __always_inline unsigned read_seqbegin(const seqlock_t *sl)
 {
@@ -92,6 +94,8 @@ repeat:
 	smp_rmb();
 	if (unlikely(ret & 1)) {
 		cpu_relax();
+		if (need_to_giveup(sl))
+			return ret;
 		goto repeat;
 	}
 
--- linux-2.6.38.orig/fs/dcache.c
+++ linux-2.6.38/fs/dcache.c
@@ -2861,6 +2861,7 @@ int is_subdir(struct dentry *new_dentry,
 	if (new_dentry == old_dentry)
 		return 1;
 
+	current->retry_vfsmntlock = 0;
 	do {
 		/* for restarting inner loop in case of seq retry */
 		seq = read_seqbegin(&rename_lock);
@@ -2874,11 +2875,23 @@ int is_subdir(struct dentry *new_dentry,
 		else
 			result = 0;
 		rcu_read_unlock();
-	} while (read_seqretry(&rename_lock, seq));
+	} while (read_seqretry(&rename_lock, seq) && !current->retry_vfsmntlock);
 
 	return result;
 }
 
+bool need_to_giveup(const seqlock_t *sl)
+{
+	if (sl == &rename_lock && current->vfsmntlock_held_for_write &&
+	    need_resched()) {
+		current->retry_vfsmntlock = true;
+		WARN(1, "Requesting for releasing vfsmount_lock");
+		return true;
+	}
+	return false;
+}
+EXPORT_SYMBOL(need_to_giveup);
+
 int path_is_under(struct path *path1, struct path *path2)
 {
 	struct vfsmount *mnt = path1->mnt;
--- linux-2.6.38.orig/fs/namespace.c
+++ linux-2.6.38/fs/namespace.c
@@ -2515,7 +2515,9 @@ SYSCALL_DEFINE2(pivot_root, const char _
 		goto out2; /* not attached */
 	/* make sure we can reach put_old from new_root */
 	tmp = old.mnt;
+retry_vfsmnt_lock:
 	br_write_lock(vfsmount_lock);
+	current->vfsmntlock_held_for_write = 1;
 	if (tmp != new.mnt) {
 		for (;;) {
 			if (tmp->mnt_parent == tmp)
@@ -2536,6 +2538,7 @@ SYSCALL_DEFINE2(pivot_root, const char _
 	attach_mnt(new.mnt, &root_parent);
 	touch_mnt_namespace(current->nsproxy->mnt_ns);
 	br_write_unlock(vfsmount_lock);
+	current->vfsmntlock_held_for_write = 0;
 	chroot_fs_refs(&root, &new);
 
 	error = 0;
@@ -2552,6 +2555,9 @@ out0:
 	return error;
 out3:
 	br_write_unlock(vfsmount_lock);
+	current->vfsmntlock_held_for_write = 0;
+	if (current->retry_vfsmntlock)
+		goto retry_vfsmnt_lock;
 	goto out2;
 }
 

You will see warning like below.

[  330.216989] ------------[ cut here ]------------
[  330.218601] WARNING: at fs/dcache.c:2888 need_to_giveup+0x52/0x60()
[  330.219509] Hardware name: VMware Virtual Platform
[  330.220644] Requesting for releasing vfsmount_lock
[  330.221426] Modules linked in: ipv6 video sbs sbshc battery ac floppy rtc_cmos button rtc_core serio_raw rtc_lib pcnet32 mii i2c_piix4 i2c_core mptspi mptscsih mptbase scsi_transport_spi ext3 jbd mbcache
[  330.230432] Pid: 8936, comm: pivot_root Tainted: G        W   2.6.38 #2
[  330.232003] Call Trace:
[  330.233153]  [<c04d2bb2>] ? need_to_giveup+0x52/0x60
[  330.234420]  [<c043f6bc>] ? warn_slowpath_common+0x7c/0xa0
[  330.235418]  [<c04d2bb2>] ? need_to_giveup+0x52/0x60
[  330.236417]  [<c043f75e>] ? warn_slowpath_fmt+0x2e/0x30
[  330.237459]  [<c04d2bb2>] ? need_to_giveup+0x52/0x60
[  330.238492]  [<c04d2d37>] ? is_subdir+0xb7/0xe0
[  330.239429]  [<c04d2cbd>] ? is_subdir+0x3d/0xe0
[  330.240420]  [<c04da8eb>] ? sys_pivot_root+0x22b/0x2a0
[  330.241775]  [<c06c519c>] ? restore_all_notrace+0x0/0x18
[  330.243005]  [<c04289a0>] ? do_page_fault+0x0/0x420
[  330.244414]  [<c0402c50>] ? sysenter_do_call+0x12/0x36
[  330.245416] ---[ end trace 5017bf44a4ddf1e2 ]---

3.6.37 seems to be OK because __d_path() was protected by dcache_lock.

Regards.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-18 10:59   ` Tetsuo Handa
@ 2011-03-18 11:06     ` Al Viro
  2011-03-18 11:54       ` Tetsuo Handa
  2011-03-18 12:07       ` Al Viro
  0 siblings, 2 replies; 13+ messages in thread
From: Al Viro @ 2011-03-18 11:06 UTC (permalink / raw)
  To: Tetsuo Handa; +Cc: npiggin, linux-fsdevel

On Fri, Mar 18, 2011 at 07:59:08PM +0900, Tetsuo Handa wrote:
> I established steps to reproduce.
> 
> On a 2.6.38 kernel built with CONFIG_SMP=y running on an SMP machine, run
> 
>   while :; do newns /sbin/pivot_root /proc/ /proc/sys/; done
> 
> on one terminal and run
> 
>   while :; do /bin/ls -l /proc/*/exe; done
> 
> on another terminal. (The "newns" is a program that unshares the mnt namespace
> before execve() using CLONE_NEWNS.)
> 
> Below patch releases/reacquires vfsmount_lock when rescheduling is required.
> ---
>  fs/dcache.c             |   15 ++++++++++++++-
>  fs/namespace.c          |    6 ++++++
>  include/linux/sched.h   |    2 ++
>  include/linux/seqlock.h |    4 ++++
>  4 files changed, 26 insertions(+), 1 deletion(-)

That's incredibly ugly.  I agree that the deadlock exists and needs to be
dealt with, but not that way.  _Strongly_ NAKed.  I'll see what I can come
up with, but that variant is not an option.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-18 11:06     ` Al Viro
@ 2011-03-18 11:54       ` Tetsuo Handa
  2011-03-18 12:07       ` Al Viro
  1 sibling, 0 replies; 13+ messages in thread
From: Tetsuo Handa @ 2011-03-18 11:54 UTC (permalink / raw)
  To: viro; +Cc: npiggin, linux-fsdevel

Al Viro wrote:
> That's incredibly ugly.  I agree that the deadlock exists and needs to be
> dealt with, but not that way.  _Strongly_ NAKed.  I'll see what I can come
> up with, but that variant is not an option.

Of course I didn't intend the patch for commit.
I showed the patch for identifying the location.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-18 11:06     ` Al Viro
  2011-03-18 11:54       ` Tetsuo Handa
@ 2011-03-18 12:07       ` Al Viro
  2011-03-18 12:13         ` Al Viro
  2011-03-18 12:52         ` Al Viro
  1 sibling, 2 replies; 13+ messages in thread
From: Al Viro @ 2011-03-18 12:07 UTC (permalink / raw)
  To: Tetsuo Handa; +Cc: npiggin, linux-fsdevel

On Fri, Mar 18, 2011 at 11:06:03AM +0000, Al Viro wrote:

> That's incredibly ugly.  I agree that the deadlock exists and needs to be
> dealt with, but not that way.  _Strongly_ NAKed.  I'll see what I can come
> up with, but that variant is not an option.

Actually, why do we hold vfsmount_lock over that loop at all?  We already
hold namespace_sem, so ->mnt_parent is protected...

FWIW, there's a thing I really don't like about that area - I would really
prefer to have namespace_sem nest _inside_ i_mutex and have no fs operations
whatsoever done under it.  Note that we already take care (mostly) to
keep actual fs shutdowns outside of it.

The real obstacle is follow_down() we do under namespace_sem on several
paths; otherwise we'd be able to grab i_mutex first and be done with that.
Moreover, we have extra ugliness in follow_down(); I really wonder
what is the only instance trying to do here.

Look: we pass mounting_here == true to autofs4_d_manage().  It sees the
flag, then checks if we have DCACHE_MOUNTED set and returns either -EISDIR
or 0.  -EISDIR leads to follow_down() returning 0 immediately.  0 leads
to trying to cross the mountpoint.  First of all, we could as well return
0 regardless - if DCACHE_MOUNTED is not set, follow_down() will see that
and return 0 since there's nothing left to do.

What's more, we have a funny situation here - we might as well replace
                if (managed & DCACHE_MANAGE_TRANSIT) {
with
                if (!mounting_here && managed & DCACHE_MANAGE_TRANSIT) {
in follow_down() and lose that argument of ->d_manage().

So let's do this:

lock_mount(path, follow)
retry:
	lock path->dentry->d_inode
	if unlikely(can't mount)
		unlock
		fail
	grab namespace_sem
	if !follow || likely(lookup_mnt() returns NULL)
		we are done
	drop namespace_sem
	unlock
	drop path
	replace it with result of lookup_mnt() (and its ->mnt_root)
	goto retry;

and use that (local to fs/namespace.c) in do_add_mount()/do_move_mount()/
do_loopback() (with follow = 1) and pivot_root() (follow = 0).  BTW,
the lack of following in do_loopback() looks like a bug...
Also in do_loopback(): take release_mounts() after unlocking everything.
graft_tree() doesn't grab i_mutex - callers take it.
follow_down() loses mounting_here argument and so does ->d_manage().
cant_mount() calls are all merged into one in lock_mount().

Comments?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-18 12:07       ` Al Viro
@ 2011-03-18 12:13         ` Al Viro
  2011-03-18 12:52         ` Al Viro
  1 sibling, 0 replies; 13+ messages in thread
From: Al Viro @ 2011-03-18 12:13 UTC (permalink / raw)
  To: Tetsuo Handa; +Cc: npiggin, linux-fsdevel

On Fri, Mar 18, 2011 at 12:07:48PM +0000, Al Viro wrote:

> Actually, why do we hold vfsmount_lock over that loop at all?  We already
> hold namespace_sem, so ->mnt_parent is protected...

Argh...  No, it isn't.  We flip it to final (mnt->mnt_parent = mnt)
outside of namespace_sem in release_mounts().  HOWEVER, by that point
we have already cleared ->mnt_ns - under namespace_sem.

So what we need is check_mnt(new.mnt) in addition to test for root.mnt
we already have there.  That'll be enough.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-18 12:07       ` Al Viro
  2011-03-18 12:13         ` Al Viro
@ 2011-03-18 12:52         ` Al Viro
  2011-03-18 13:18           ` Al Viro
  1 sibling, 1 reply; 13+ messages in thread
From: Al Viro @ 2011-03-18 12:52 UTC (permalink / raw)
  To: Tetsuo Handa; +Cc: npiggin, linux-fsdevel

On Fri, Mar 18, 2011 at 12:07:48PM +0000, Al Viro wrote:
> lock_mount(path, follow)
> retry:
> 	lock path->dentry->d_inode
> 	if unlikely(can't mount)
> 		unlock
> 		fail
> 	grab namespace_sem
> 	if !follow || likely(lookup_mnt() returns NULL)
> 		we are done
> 	drop namespace_sem
> 	unlock
> 	drop path
> 	replace it with result of lookup_mnt() (and its ->mnt_root)
> 	goto retry;
> 
> and use that (local to fs/namespace.c) in do_add_mount()/do_move_mount()/
> do_loopback() (with follow = 1) and pivot_root() (follow = 0).  BTW,
> the lack of following in do_loopback() looks like a bug...

So's the lack of following on old in pivot_root, actually.  IOW, follow
argument is always 1...

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-18 12:52         ` Al Viro
@ 2011-03-18 13:18           ` Al Viro
  2011-03-19  2:39             ` Tetsuo Handa
  0 siblings, 1 reply; 13+ messages in thread
From: Al Viro @ 2011-03-18 13:18 UTC (permalink / raw)
  To: Tetsuo Handa; +Cc: npiggin, linux-fsdevel

	See #untested in vfs-2.6.git.  I think it should do it, but
it *is* completely untested at the moment.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-18 13:18           ` Al Viro
@ 2011-03-19  2:39             ` Tetsuo Handa
  2011-03-23 23:00               ` Greg KH
  0 siblings, 1 reply; 13+ messages in thread
From: Tetsuo Handa @ 2011-03-19  2:39 UTC (permalink / raw)
  To: viro; +Cc: npiggin, linux-fsdevel

Al Viro wrote:
> 	See #untested in vfs-2.6.git.  I think it should do it, but
> it *is* completely untested at the moment.

As far as I can test, I did not find any problems. Thank you.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-19  2:39             ` Tetsuo Handa
@ 2011-03-23 23:00               ` Greg KH
  2011-03-24  0:04                 ` Tetsuo Handa
  0 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2011-03-23 23:00 UTC (permalink / raw)
  To: Tetsuo Handa; +Cc: viro, npiggin, linux-fsdevel

On Sat, Mar 19, 2011 at 11:39:19AM +0900, Tetsuo Handa wrote:
> Al Viro wrote:
> > 	See #untested in vfs-2.6.git.  I think it should do it, but
> > it *is* completely untested at the moment.
> 
> As far as I can test, I did not find any problems. Thank you.

Did this fix go to Linus?  If so, any pointers to the git commit id?
I'm guessing I will want this in the .38-stable tree?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-23 23:00               ` Greg KH
@ 2011-03-24  0:04                 ` Tetsuo Handa
  2011-03-24  0:10                   ` Greg KH
  0 siblings, 1 reply; 13+ messages in thread
From: Tetsuo Handa @ 2011-03-24  0:04 UTC (permalink / raw)
  To: greg; +Cc: viro, npiggin, linux-fsdevel

Greg KH wrote:
> On Sat, Mar 19, 2011 at 11:39:19AM +0900, Tetsuo Handa wrote:
> > Al Viro wrote:
> > > 	See #untested in vfs-2.6.git.  I think it should do it, but
> > > it *is* completely untested at the moment.
> > 
> > As far as I can test, I did not find any problems. Thank you.
> 
> Did this fix go to Linus?  If so, any pointers to the git commit id?

It is commit 27cb1572e3e6bb1f8cf6bb3d74c914a87b131792 "fix deadlock in pivot_root()"
in linux-2.6.git .

> I'm guessing I will want this in the .38-stable tree?

Yes. We are waiting for tests by Al.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [2.6.38] Deadlock between rename_lock and vfsmount_lock.
  2011-03-24  0:04                 ` Tetsuo Handa
@ 2011-03-24  0:10                   ` Greg KH
  0 siblings, 0 replies; 13+ messages in thread
From: Greg KH @ 2011-03-24  0:10 UTC (permalink / raw)
  To: Tetsuo Handa; +Cc: viro, npiggin, linux-fsdevel

On Thu, Mar 24, 2011 at 09:04:28AM +0900, Tetsuo Handa wrote:
> Greg KH wrote:
> > On Sat, Mar 19, 2011 at 11:39:19AM +0900, Tetsuo Handa wrote:
> > > Al Viro wrote:
> > > > 	See #untested in vfs-2.6.git.  I think it should do it, but
> > > > it *is* completely untested at the moment.
> > > 
> > > As far as I can test, I did not find any problems. Thank you.
> > 
> > Did this fix go to Linus?  If so, any pointers to the git commit id?
> 
> It is commit 27cb1572e3e6bb1f8cf6bb3d74c914a87b131792 "fix deadlock in pivot_root()"
> in linux-2.6.git .
> 
> > I'm guessing I will want this in the .38-stable tree?
> 
> Yes. We are waiting for tests by Al.

Great, thanks for letting me know, I'll watch out for the above patch to
hit Linus's tree.

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2011-03-24  0:10 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-16  8:54 [2.6.38] Possible deadlock at pivot_root? Tetsuo Handa
2011-03-17  5:01 ` [2.6.38] Deadlock between rename_lock and vfsmount_lock Tetsuo Handa
2011-03-18 10:59   ` Tetsuo Handa
2011-03-18 11:06     ` Al Viro
2011-03-18 11:54       ` Tetsuo Handa
2011-03-18 12:07       ` Al Viro
2011-03-18 12:13         ` Al Viro
2011-03-18 12:52         ` Al Viro
2011-03-18 13:18           ` Al Viro
2011-03-19  2:39             ` Tetsuo Handa
2011-03-23 23:00               ` Greg KH
2011-03-24  0:04                 ` Tetsuo Handa
2011-03-24  0:10                   ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).