* [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).