linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [patch, validator] fix proc_subdir_lock related deadlock
@ 2006-01-25 17:03 Ingo Molnar
  2006-01-25 17:14 ` Steven Rostedt
  0 siblings, 1 reply; 8+ messages in thread
From: Ingo Molnar @ 2006-01-25 17:03 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Steven Rostedt, linux-kernel

proc_subdir_lock can also be used from softirq (tasklet) context, which 
may lead to deadlocks.

This bug was found via the lock validator:

  ============================
  [ BUG: illegal lock usage! ]
  ----------------------------
  illegal {enabled-softirqs} -> {used-in-softirq} usage.
  ifup/2283 [HC0[0]:SC1[2]:HE1:SE0] takes {proc_subdir_lock [u:25]}, at:
   [<c0196363>] remove_proc_entry+0x33/0x1f0
  {enabled-softirqs} state was registered at:
   [<c04d7c0d>] _spin_unlock_bh+0xd/0x10
  hardirqs last enabled at: [<c04d7bb5>] _spin_unlock_irqrestore+0x25/0x30
  softirqs last enabled at: [<c0127624>] free_uid+0x24/0x80
  
  other info that might help in debugging this:
  ------------------------------
  | showing all locks held by: |  (ifup/2283 [c31a6790, 125]):
  ------------------------------
  
   [<c010432d>] show_trace+0xd/0x10
   [<c0104347>] dump_stack+0x17/0x20
   [<c0137181>] print_usage_bug+0x1e1/0x200
   [<c0137739>] mark_lock+0x259/0x290
   [<c0137bd5>] debug_lock_chain_spin+0x465/0x10f0
   [<c0264a6d>] _raw_spin_lock+0x2d/0x90
   [<c04d7a18>] _spin_lock+0x8/0x10
   [<c0196363>] remove_proc_entry+0x33/0x1f0
   [<c0141d79>] unregister_handler_proc+0x19/0x20
   [<c014153b>] free_irq+0x7b/0xe0
   [<c02f15e2>] floppy_release_irq_and_dma+0x1b2/0x210
   [<c02efad7>] set_dor+0xc7/0x1b0
   [<c02f2b51>] motor_off_callback+0x21/0x30
   [<c01272b5>] run_timer_softirq+0xf5/0x1f0
   [<c0122c17>] __do_softirq+0x87/0x120
   [<c0105519>] do_softirq+0x69/0xb0
   =======================

the way i fixed this bug was to make all uses of the proc_subdir_lock 
softirq-safe. Alternatively, we may want to forbid the use of this lock 
(and remove_proc_entry()) from softirq contexts - but a quick glance 
showed that quite some drivers are affected, and it would need a full 
review to make sure the block is never taken from a softirq context. So 
this seemed the safest fix.

the patched 2.6.16-rc1-mm1 kernel now passes validation.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

----

 fs/proc/generic.c      |   34 +++++++++++++++++++---------------
 fs/proc/proc_devtree.c |    4 ++--
 2 files changed, 21 insertions(+), 17 deletions(-)

Index: linux/fs/proc/generic.c
===================================================================
--- linux.orig/fs/proc/generic.c
+++ linux/fs/proc/generic.c
@@ -30,6 +30,10 @@ static ssize_t proc_file_write(struct fi
 			       size_t count, loff_t *ppos);
 static loff_t proc_file_lseek(struct file *, loff_t, int);
 
+/*
+ * Is mostly used from process, but can occasionally be used from
+ * softirq context too - hence all locking must be softirq-safe:
+ */
 DEFINE_SPINLOCK(proc_subdir_lock);
 
 int proc_match(int len, const char *name, struct proc_dir_entry *de)
@@ -282,7 +286,7 @@ static int xlate_proc_name(const char *n
 	int			len;
 	int 			rtn = 0;
 
-	spin_lock(&proc_subdir_lock);
+	spin_lock_bh(&proc_subdir_lock);
 	de = &proc_root;
 	while (1) {
 		next = strchr(cp, '/');
@@ -303,7 +307,7 @@ static int xlate_proc_name(const char *n
 	*residual = cp;
 	*ret = de;
 out:
-	spin_unlock(&proc_subdir_lock);
+	spin_unlock_bh(&proc_subdir_lock);
 	return rtn;
 }
 
@@ -389,7 +393,7 @@ struct dentry *proc_lookup(struct inode 
 	int error = -ENOENT;
 
 	lock_kernel();
-	spin_lock(&proc_subdir_lock);
+	spin_lock_bh(&proc_subdir_lock);
 	de = PDE(dir);
 	if (de) {
 		for (de = de->subdir; de ; de = de->next) {
@@ -398,15 +402,15 @@ struct dentry *proc_lookup(struct inode 
 			if (!memcmp(dentry->d_name.name, de->name, de->namelen)) {
 				unsigned int ino = de->low_ino;
 
-				spin_unlock(&proc_subdir_lock);
+				spin_unlock_bh(&proc_subdir_lock);
 				error = -EINVAL;
 				inode = proc_get_inode(dir->i_sb, ino, de);
-				spin_lock(&proc_subdir_lock);
+				spin_lock_bh(&proc_subdir_lock);
 				break;
 			}
 		}
 	}
-	spin_unlock(&proc_subdir_lock);
+	spin_unlock_bh(&proc_subdir_lock);
 	unlock_kernel();
 
 	if (inode) {
@@ -460,13 +464,13 @@ int proc_readdir(struct file * filp,
 			filp->f_pos++;
 			/* fall through */
 		default:
-			spin_lock(&proc_subdir_lock);
+			spin_lock_bh(&proc_subdir_lock);
 			de = de->subdir;
 			i -= 2;
 			for (;;) {
 				if (!de) {
 					ret = 1;
-					spin_unlock(&proc_subdir_lock);
+					spin_unlock_bh(&proc_subdir_lock);
 					goto out;
 				}
 				if (!i)
@@ -477,15 +481,15 @@ int proc_readdir(struct file * filp,
 
 			do {
 				/* filldir passes info to user space */
-				spin_unlock(&proc_subdir_lock);
+				spin_unlock_bh(&proc_subdir_lock);
 				if (filldir(dirent, de->name, de->namelen, filp->f_pos,
 					    de->low_ino, de->mode >> 12) < 0)
 					goto out;
-				spin_lock(&proc_subdir_lock);
+				spin_lock_bh(&proc_subdir_lock);
 				filp->f_pos++;
 				de = de->next;
 			} while (de);
-			spin_unlock(&proc_subdir_lock);
+			spin_unlock_bh(&proc_subdir_lock);
 	}
 	ret = 1;
 out:	unlock_kernel();
@@ -520,11 +524,11 @@ static int proc_register(struct proc_dir
 		return -EAGAIN;
 	dp->low_ino = i;
 
-	spin_lock(&proc_subdir_lock);
+	spin_lock_bh(&proc_subdir_lock);
 	dp->next = dir->subdir;
 	dp->parent = dir;
 	dir->subdir = dp;
-	spin_unlock(&proc_subdir_lock);
+	spin_unlock_bh(&proc_subdir_lock);
 
 	if (S_ISDIR(dp->mode)) {
 		if (dp->proc_iops == NULL) {
@@ -718,7 +722,7 @@ void remove_proc_entry(const char *name,
 		goto out;
 	len = strlen(fn);
 
-	spin_lock(&proc_subdir_lock);
+	spin_lock_bh(&proc_subdir_lock);
 	for (p = &parent->subdir; *p; p=&(*p)->next ) {
 		if (!proc_match(len, fn, *p))
 			continue;
@@ -739,7 +743,7 @@ void remove_proc_entry(const char *name,
 		}
 		break;
 	}
-	spin_unlock(&proc_subdir_lock);
+	spin_unlock_bh(&proc_subdir_lock);
 out:
 	return;
 }
Index: linux/fs/proc/proc_devtree.c
===================================================================
--- linux.orig/fs/proc/proc_devtree.c
+++ linux/fs/proc/proc_devtree.c
@@ -136,11 +136,11 @@ void proc_device_tree_add_node(struct de
 		 * properties are quite unimportant for us though, thus we
 		 * simply "skip" them here, but we do have to check.
 		 */
-		spin_lock(&proc_subdir_lock);
+		spin_lock_bh(&proc_subdir_lock);
 		for (ent = de->subdir; ent != NULL; ent = ent->next)
 			if (!strcmp(ent->name, pp->name))
 				break;
-		spin_unlock(&proc_subdir_lock);
+		spin_unlock_bh(&proc_subdir_lock);
 		if (ent != NULL) {
 			printk(KERN_WARNING "device-tree: property \"%s\" name"
 			       " conflicts with node in %s\n", pp->name,

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

* Re: [patch, validator] fix proc_subdir_lock related deadlock
  2006-01-25 17:03 [patch, validator] fix proc_subdir_lock related deadlock Ingo Molnar
@ 2006-01-25 17:14 ` Steven Rostedt
  2006-01-25 18:08   ` Ingo Molnar
  0 siblings, 1 reply; 8+ messages in thread
From: Steven Rostedt @ 2006-01-25 17:14 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Andrew Morton, linux-kernel

On Wed, 2006-01-25 at 18:03 +0100, Ingo Molnar wrote:
> proc_subdir_lock can also be used from softirq (tasklet) context, which 
> may lead to deadlocks.
> 
> This bug was found via the lock validator:
> 

Thanks Ingo,

I stressed in sending the patch that there was a big assumption that the
calls would not be done in (soft)irq context.  I just didn't want to add
overhead if it wasn't needed.  But I guess that this is needed until we
can remove all the instances that use it in softirq context. But that's
for a later patch.

Acked-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve



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

* Re: [patch, validator] fix proc_subdir_lock related deadlock
  2006-01-25 17:14 ` Steven Rostedt
@ 2006-01-25 18:08   ` Ingo Molnar
  2006-01-25 18:14     ` [patch, validator] fix files_lock " Ingo Molnar
  2006-01-25 18:23     ` [patch, validator] fix proc_subdir_lock " Andrew Morton
  0 siblings, 2 replies; 8+ messages in thread
From: Ingo Molnar @ 2006-01-25 18:08 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Andrew Morton, linux-kernel, Alexander Viro


* Steven Rostedt <rostedt@goodmis.org> wrote:

> > proc_subdir_lock can also be used from softirq (tasklet) context, which 
> > may lead to deadlocks.
> > 
> > This bug was found via the lock validator:
> > 
> 
> Thanks Ingo,
> 
> I stressed in sending the patch that there was a big assumption that 
> the calls would not be done in (soft)irq context.  I just didn't want 
> to add overhead if it wasn't needed.  But I guess that this is needed 
> until we can remove all the instances that use it in softirq context. 
> But that's for a later patch.

the validator just found another problem with this lock, pointing out 
that files_lock nests inside of proc_subdir_lock, and that files_lock is 
a softirq-unsafe lock, creating another (unlikely but possible) deadlock 
scenario:

 =====================================
 [ BUG: lock inversion bug detected! ]
 -------------------------------------
 grep/2290 just changed the state of lock {proc_subdir_lock} at:
  [<c0196e53>] remove_proc_entry+0x33/0x1f0
 but this lock took lock {files_lock} in the past,
 acquired at: [<c0196ece>] remove_proc_entry+0xae/0x1f0
 and interrupts could create an inverse lock dependency between them,
 which could lead to deadlocks!
 other info that might help in debugging this:
 ------------------------------
 | showing all locks held by: |  (grep/2290 [c321c790, 125]):
 ------------------------------

  [<c010432d>] show_trace+0xd/0x10
  [<c0104347>] dump_stack+0x17/0x20
  [<c0137b11>] check_no_lock_2_mask+0x131/0x180
  [<c0137ffb>] mark_lock+0xfb/0x2a0
  [<c01387b3>] debug_lock_chain+0x613/0x10d0
  [<c01392ad>] debug_lock_chain_spin+0x3d/0x60
  [<c02656ed>] _raw_spin_lock+0x2d/0x90
  [<c04d88d2>] _spin_lock_bh+0x12/0x20
  [<c0196e53>] remove_proc_entry+0x33/0x1f0
  [<c01427c9>] unregister_handler_proc+0x19/0x20
  [<c0141f8b>] free_irq+0x7b/0xe0
  [<c02f2302>] floppy_release_irq_and_dma+0x1b2/0x210
  [<c02f07f7>] set_dor+0xc7/0x1b0
  [<c02f3871>] motor_off_callback+0x21/0x30
  [<c01273a5>] run_timer_softirq+0xf5/0x1f0
  [<c0122cf7>] __do_softirq+0x97/0x130
  [<c0105519>] do_softirq+0x69/0x100
  =======================
  [<c01229a9>] irq_exit+0x39/0x50
  [<c010f4cc>] smp_apic_timer_interrupt+0x4c/0x50
  [<c010393b>] apic_timer_interrupt+0x27/0x2c

to solve this we must either change files_lock to be softirq-safe too 
(bleh!), or we must forbid remove_proc_entry() use from softirq 
contexts. Neither is a happy solution - remove_proc_entry() is used 
within free_irq(), and who knows how many drivers do free_irq() in 
softirq/tasklet context ...

Andrew, this needs to be resolved before v2.6.16, correct? Steve's patch 
solves a real bug in the upstream kernel.

	Ingo

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

* [patch, validator] fix files_lock related deadlock
  2006-01-25 18:08   ` Ingo Molnar
@ 2006-01-25 18:14     ` Ingo Molnar
  2006-01-25 18:23     ` [patch, validator] fix proc_subdir_lock " Andrew Morton
  1 sibling, 0 replies; 8+ messages in thread
From: Ingo Molnar @ 2006-01-25 18:14 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Andrew Morton, linux-kernel, Alexander Viro


> to solve this we must either change files_lock to be softirq-safe too 
> (bleh!), or we must forbid remove_proc_entry() use from softirq 
> contexts. Neither is a happy solution - remove_proc_entry() is used 
> within free_irq(), and who knows how many drivers do free_irq() in 
> softirq/tasklet context ...
> 
> Andrew, this needs to be resolved before v2.6.16, correct? Steve's 
> patch solves a real bug in the upstream kernel.

the patch below does the easier and safer change: it makes files_lock 
softirq-safe. (A quick test shows that the validator does not complain 
when this patch is applied too - so it seems the 'softirq effect' does 
not spread to other VFS locks.)

	Ingo

-----
the validator just found another problem with this lock, pointing out 
that files_lock nests inside of proc_subdir_lock, and that files_lock is 
a softirq-unsafe lock, creating another (unlikely but possible) deadlock 
scenario:

 =====================================
 [ BUG: lock inversion bug detected! ]
 -------------------------------------
 grep/2290 just changed the state of lock {proc_subdir_lock} at:
  [<c0196e53>] remove_proc_entry+0x33/0x1f0
 but this lock took lock {files_lock} in the past,
 acquired at: [<c0196ece>] remove_proc_entry+0xae/0x1f0
 and interrupts could create an inverse lock dependency between them,
 which could lead to deadlocks!
 other info that might help in debugging this:
 ------------------------------
 | showing all locks held by: |  (grep/2290 [c321c790, 125]):
 ------------------------------

  [<c010432d>] show_trace+0xd/0x10
  [<c0104347>] dump_stack+0x17/0x20
  [<c0137b11>] check_no_lock_2_mask+0x131/0x180
  [<c0137ffb>] mark_lock+0xfb/0x2a0
  [<c01387b3>] debug_lock_chain+0x613/0x10d0
  [<c01392ad>] debug_lock_chain_spin+0x3d/0x60
  [<c02656ed>] _raw_spin_lock+0x2d/0x90
  [<c04d88d2>] _spin_lock_bh+0x12/0x20
  [<c0196e53>] remove_proc_entry+0x33/0x1f0
  [<c01427c9>] unregister_handler_proc+0x19/0x20
  [<c0141f8b>] free_irq+0x7b/0xe0
  [<c02f2302>] floppy_release_irq_and_dma+0x1b2/0x210
  [<c02f07f7>] set_dor+0xc7/0x1b0
  [<c02f3871>] motor_off_callback+0x21/0x30
  [<c01273a5>] run_timer_softirq+0xf5/0x1f0
  [<c0122cf7>] __do_softirq+0x97/0x130
  [<c0105519>] do_softirq+0x69/0x100
  =======================
  [<c01229a9>] irq_exit+0x39/0x50
  [<c010f4cc>] smp_apic_timer_interrupt+0x4c/0x50
  [<c010393b>] apic_timer_interrupt+0x27/0x2c

to solve this we must either change files_lock to be softirq-safe too 
(bleh!), or we must forbid remove_proc_entry() use from softirq 
contexts. Neither is a happy solution - remove_proc_entry() is used 
within free_irq(), and who knows how many drivers do free_irq() in 
softirq/tasklet context ...

the patch below makes files_lock softirq-safe.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

----

 include/linux/fs.h |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

Index: linux/include/linux/fs.h
===================================================================
--- linux.orig/include/linux/fs.h
+++ linux/include/linux/fs.h
@@ -648,9 +648,13 @@ struct file {
 #endif /* #ifdef CONFIG_EPOLL */
 	struct address_space	*f_mapping;
 };
+/*
+ * files_lock can also be taken from softirq context:
+ */
 extern spinlock_t files_lock;
-#define file_list_lock() spin_lock(&files_lock);
-#define file_list_unlock() spin_unlock(&files_lock);
+
+#define file_list_lock()	spin_lock_bh(&files_lock);
+#define file_list_unlock()	spin_unlock_bh(&files_lock);
 
 #define get_file(x)	atomic_inc(&(x)->f_count)
 #define file_count(x)	atomic_read(&(x)->f_count)

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

* Re: [patch, validator] fix proc_subdir_lock related deadlock
  2006-01-25 18:08   ` Ingo Molnar
  2006-01-25 18:14     ` [patch, validator] fix files_lock " Ingo Molnar
@ 2006-01-25 18:23     ` Andrew Morton
  2006-01-25 20:21       ` Ingo Molnar
  2006-01-26  0:02       ` [patch, lock validator] fix proc_inum_lock " Ingo Molnar
  1 sibling, 2 replies; 8+ messages in thread
From: Andrew Morton @ 2006-01-25 18:23 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: rostedt, linux-kernel, viro

Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > > proc_subdir_lock can also be used from softirq (tasklet) context, which 
> > > may lead to deadlocks.
> > > 
> > > This bug was found via the lock validator:
> > > 
> > 
> > Thanks Ingo,
> > 
> > I stressed in sending the patch that there was a big assumption that 
> > the calls would not be done in (soft)irq context.  I just didn't want 
> > to add overhead if it wasn't needed.  But I guess that this is needed 
> > until we can remove all the instances that use it in softirq context. 
> > But that's for a later patch.
> 
> the validator just found another problem with this lock, pointing out 
> that files_lock nests inside of proc_subdir_lock, and that files_lock is 
> a softirq-unsafe lock, creating another (unlikely but possible) deadlock 
> scenario:

files_lock can be taken on the free_irq() path: proc_kill_inodes().

> ...
> to solve this we must either change files_lock to be softirq-safe too 
> (bleh!), or we must forbid remove_proc_entry() use from softirq 
> contexts. Neither is a happy solution - remove_proc_entry() is used 
> within free_irq(), and who knows how many drivers do free_irq() in 
> softirq/tasklet context ...

free_irq()'s /proc fiddling has always been a pain - we just shouldn't be
doing filesystem things in irq/bh context.

> Andrew, this needs to be resolved before v2.6.16, correct? Steve's patch 
> solves a real bug in the upstream kernel.

It's not a very big bug - I think only Steve hit it, and that with a
stress-test which was somewhat tuned to hit it.

So we can afford to sit on the problem for a while, as long as someone is
working on a broader /proc-sanity fix.  But nobody will do that.

I wonder if we can just punt the unregister_handler_proc/kfree up to a
keventd callback.

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

* Re: [patch, validator] fix proc_subdir_lock related deadlock
  2006-01-25 18:23     ` [patch, validator] fix proc_subdir_lock " Andrew Morton
@ 2006-01-25 20:21       ` Ingo Molnar
  2006-01-26  0:02       ` [patch, lock validator] fix proc_inum_lock " Ingo Molnar
  1 sibling, 0 replies; 8+ messages in thread
From: Ingo Molnar @ 2006-01-25 20:21 UTC (permalink / raw)
  To: Andrew Morton; +Cc: rostedt, linux-kernel, viro


* Andrew Morton <akpm@osdl.org> wrote:

> > to solve this we must either change files_lock to be softirq-safe too 
> > (bleh!), or we must forbid remove_proc_entry() use from softirq 
> > contexts. Neither is a happy solution - remove_proc_entry() is used 
> > within free_irq(), and who knows how many drivers do free_irq() in 
> > softirq/tasklet context ...
> 
> free_irq()'s /proc fiddling has always been a pain - we just shouldn't 
> be doing filesystem things in irq/bh context.

the second patch i sent is quite straightforward.

> > Andrew, this needs to be resolved before v2.6.16, correct? Steve's patch 
> > solves a real bug in the upstream kernel.
> 
> It's not a very big bug - I think only Steve hit it, and that with a 
> stress-test which was somewhat tuned to hit it.

still ...

> So we can afford to sit on the problem for a while, as long as someone 
> is working on a broader /proc-sanity fix.  But nobody will do that.
> 
> I wonder if we can just punt the unregister_handler_proc/kfree up to a 
> keventd callback.

i'd rather do the files_lock change i sent, and perhaps add a 
WARN_ON_ONCE() to all known places that do a free_irq() from softirq 
context.

	Ingo

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

* [patch, lock validator] fix proc_inum_lock related deadlock
  2006-01-25 18:23     ` [patch, validator] fix proc_subdir_lock " Andrew Morton
  2006-01-25 20:21       ` Ingo Molnar
@ 2006-01-26  0:02       ` Ingo Molnar
  2006-01-26  0:11         ` Ingo Molnar
  1 sibling, 1 reply; 8+ messages in thread
From: Ingo Molnar @ 2006-01-26  0:02 UTC (permalink / raw)
  To: Andrew Morton; +Cc: rostedt, linux-kernel, viro

there's another VFS lock that just popped up, hopefully the last one.  
Fix below. (All this is still related to proc_subdir_lock, and the 
original BKL bug it fixed.)

	Ingo

-------------

&proc_inum_lock also nests within proc_subdir_lock, and &proc_inum_lock
is used in a softirq-unsafe manner. The lock validator noticed the
following scenario:

  =====================================
  [ BUG: lock inversion bug detected! ]
  -------------------------------------
  ifup-eth/2308 just changed the state of lock {proc_subdir_lock} at:
   [<c0197083>] remove_proc_entry+0x33/0x1f0
  but this lock took lock {proc_inum_lock} in the past, acquired at:
   [<c0196fee>] free_proc_entry+0x2e/0x90
  and interrupts could create an inverse lock dependency between them,
  which could lead to deadlocks!

  other info that might help in debugging this:
  locks held by ifup-eth/2308:
   [<c010432d>] show_trace+0xd/0x10
   [<c0104347>] dump_stack+0x17/0x20
   [<c0137a41>] check_no_lock_2_mask+0x131/0x180
   [<c013852b>] mark_lock+0xfb/0x2a0
   [<c0138b63>] debug_lock_chain+0x493/0xdc0
   [<c01394cd>] debug_lock_chain_spin+0x3d/0x60
   [<c026594d>] _raw_spin_lock+0x2d/0x90
   [<c04d91a2>] _spin_lock_bh+0x12/0x20
   [<c0197083>] remove_proc_entry+0x33/0x1f0
   [<c01429e9>] unregister_handler_proc+0x19/0x20
   [<c01421ab>] free_irq+0x7b/0xe0
   [<c02f25b2>] floppy_release_irq_and_dma+0x1b2/0x210
   [<c02f0aa7>] set_dor+0xc7/0x1b0
   [<c02f3b21>] motor_off_callback+0x21/0x30
   [<c01274d5>] run_timer_softirq+0xf5/0x1f0
   [<c0122e27>] __do_softirq+0x97/0x130
   [<c0105519>] do_softirq+0x69/0x100
   =======================

the fix is to take proc_inum_lock in a softirq-safe manner.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

----

 fs/proc/generic.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

Index: linux/fs/proc/generic.c
===================================================================
--- linux.orig/fs/proc/generic.c
+++ linux/fs/proc/generic.c
@@ -329,9 +329,9 @@ retry:
 	if (idr_pre_get(&proc_inum_idr, GFP_KERNEL) == 0)
 		return 0;
 
-	spin_lock(&proc_inum_lock);
+	spin_lock_bh(&proc_inum_lock);
 	error = idr_get_new(&proc_inum_idr, NULL, &i);
-	spin_unlock(&proc_inum_lock);
+	spin_unlock_bh(&proc_inum_lock);
 	if (error == -EAGAIN)
 		goto retry;
 	else if (error)
@@ -350,9 +350,9 @@ static void release_inode_number(unsigne
 {
 	int id = (inum - PROC_DYNAMIC_FIRST) | ~MAX_ID_MASK;
 
-	spin_lock(&proc_inum_lock);
+	spin_lock_bh(&proc_inum_lock);
 	idr_remove(&proc_inum_idr, id);
-	spin_unlock(&proc_inum_lock);
+	spin_unlock_bh(&proc_inum_lock);
 }
 
 static void *proc_follow_link(struct dentry *dentry, struct nameidata *nd)

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

* Re: [patch, lock validator] fix proc_inum_lock related deadlock
  2006-01-26  0:02       ` [patch, lock validator] fix proc_inum_lock " Ingo Molnar
@ 2006-01-26  0:11         ` Ingo Molnar
  0 siblings, 0 replies; 8+ messages in thread
From: Ingo Molnar @ 2006-01-26  0:11 UTC (permalink / raw)
  To: Andrew Morton; +Cc: rostedt, linux-kernel, viro


* Ingo Molnar <mingo@elte.hu> wrote:

> there's another VFS lock that just popped up, hopefully the last one.  
> Fix below. (All this is still related to proc_subdir_lock, and the 
> original BKL bug it fixed.)

bah. proc_num_idr.lock nests too ...

i guess we should stick this into free_irq():

	WARN_ON(in_interrupt());

and be done with it. If all such places are fixed then Steve's fix 
becomes complete.

	Ingo

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

end of thread, other threads:[~2006-01-26  0:11 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-25 17:03 [patch, validator] fix proc_subdir_lock related deadlock Ingo Molnar
2006-01-25 17:14 ` Steven Rostedt
2006-01-25 18:08   ` Ingo Molnar
2006-01-25 18:14     ` [patch, validator] fix files_lock " Ingo Molnar
2006-01-25 18:23     ` [patch, validator] fix proc_subdir_lock " Andrew Morton
2006-01-25 20:21       ` Ingo Molnar
2006-01-26  0:02       ` [patch, lock validator] fix proc_inum_lock " Ingo Molnar
2006-01-26  0:11         ` Ingo Molnar

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