From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org,
Arjan van de Ven <arjan@infradead.org>,
"Paul E. McKenney" <paulmck@us.ibm.com>
Subject: [patch, lock validator] fix uidhash_lock <-> RCU deadlock
Date: Wed, 25 Jan 2006 15:23:07 +0100 [thread overview]
Message-ID: <20060125142307.GA5427@elte.hu> (raw)
RCU task-struct freeing can call free_uid(), which is taking
uidhash_lock - while other users of uidhash_lock are softirq-unsafe.
This bug was found by the lock validator i'm working on:
============================
[ BUG: illegal lock usage! ]
----------------------------
illegal {enabled-softirqs} -> {used-in-softirq} usage.
swapper/0 [HC0[0]:SC1[2]:HE1:SE0] takes {uidhash_lock [u:25]}, at:
[<c025e858>] _atomic_dec_and_lock+0x48/0x80
{enabled-softirqs} state was registered at:
[<c04d7cfd>] _write_unlock_bh+0xd/0x10
hardirqs last enabled at: [<c015f278>] kmem_cache_free+0x78/0xb0
softirqs last enabled at: [<c011b2da>] copy_process+0x2ca/0xe80
other info that might help in debugging this:
------------------------------
| showing all locks held by: | (swapper/0 [c30d8790, 140]): <none>
------------------------------
[<c010432d>] show_trace+0xd/0x10
[<c0104347>] dump_stack+0x17/0x20
[<c01371d1>] print_usage_bug+0x1e1/0x200
[<c0137789>] mark_lock+0x259/0x290
[<c0137c25>] debug_lock_chain_spin+0x465/0x10f0
[<c0264abd>] _raw_spin_lock+0x2d/0x90
[<c04d7a68>] _spin_lock+0x8/0x10
[<c025e858>] _atomic_dec_and_lock+0x48/0x80
[<c0127674>] free_uid+0x14/0x70
[<c011a428>] __put_task_struct+0x38/0x130
[<c0114afd>] __put_task_struct_cb+0xd/0x10
[<c012f151>] __rcu_process_callbacks+0x81/0x180
[<c012f550>] rcu_process_callbacks+0x30/0x60
[<c0122aa4>] tasklet_action+0x54/0xd0
[<c0122c77>] __do_softirq+0x87/0x120
[<c0105519>] do_softirq+0x69/0xb0
=======================
[<c0122939>] irq_exit+0x39/0x50
[<c010f47c>] smp_apic_timer_interrupt+0x4c/0x50
[<c010393b>] apic_timer_interrupt+0x27/0x2c
[<c0101c58>] cpu_idle+0x68/0x80
[<c010e37e>] start_secondary+0x29e/0x480
[<00000000>] 0x0
[<c30d9fb4>] 0xc30d9fb4
the fix is to always take the uidhash_spinlock in a softirq-safe manner.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
----
Index: linux/kernel/user.c
===================================================================
--- linux.orig/kernel/user.c
+++ linux/kernel/user.c
@@ -13,6 +13,7 @@
#include <linux/slab.h>
#include <linux/bitops.h>
#include <linux/key.h>
+#include <linux/interrupt.h>
/*
* UID task count cache, to get fast user lookup in "alloc_uid"
@@ -27,6 +28,12 @@
static kmem_cache_t *uid_cachep;
static struct list_head uidhash_table[UIDHASH_SZ];
+
+/*
+ * The uidhash_lock is mostly taken from process context, but it is
+ * occasionally also taken from softirq/tasklet context, when
+ * task-structs get RCU-freed. Hence all locking must be softirq-safe.
+ */
static DEFINE_SPINLOCK(uidhash_lock);
struct user_struct root_user = {
@@ -83,14 +90,15 @@ struct user_struct *find_user(uid_t uid)
{
struct user_struct *ret;
- spin_lock(&uidhash_lock);
+ spin_lock_bh(&uidhash_lock);
ret = uid_hash_find(uid, uidhashentry(uid));
- spin_unlock(&uidhash_lock);
+ spin_unlock_bh(&uidhash_lock);
return ret;
}
void free_uid(struct user_struct *up)
{
+ local_bh_disable();
if (up && atomic_dec_and_lock(&up->__count, &uidhash_lock)) {
uid_hash_remove(up);
key_put(up->uid_keyring);
@@ -98,6 +106,7 @@ void free_uid(struct user_struct *up)
kmem_cache_free(uid_cachep, up);
spin_unlock(&uidhash_lock);
}
+ local_bh_enable();
}
struct user_struct * alloc_uid(uid_t uid)
@@ -105,9 +114,9 @@ struct user_struct * alloc_uid(uid_t uid
struct list_head *hashent = uidhashentry(uid);
struct user_struct *up;
- spin_lock(&uidhash_lock);
+ spin_lock_bh(&uidhash_lock);
up = uid_hash_find(uid, hashent);
- spin_unlock(&uidhash_lock);
+ spin_unlock_bh(&uidhash_lock);
if (!up) {
struct user_struct *new;
@@ -137,7 +146,7 @@ struct user_struct * alloc_uid(uid_t uid
* Before adding this, check whether we raced
* on adding the same user already..
*/
- spin_lock(&uidhash_lock);
+ spin_lock_bh(&uidhash_lock);
up = uid_hash_find(uid, hashent);
if (up) {
key_put(new->uid_keyring);
@@ -147,7 +156,7 @@ struct user_struct * alloc_uid(uid_t uid
uid_hash_insert(new, hashent);
up = new;
}
- spin_unlock(&uidhash_lock);
+ spin_unlock_bh(&uidhash_lock);
}
return up;
@@ -183,9 +192,9 @@ static int __init uid_cache_init(void)
INIT_LIST_HEAD(uidhash_table + n);
/* Insert the root user immediately (init already runs as root) */
- spin_lock(&uidhash_lock);
+ spin_lock_bh(&uidhash_lock);
uid_hash_insert(&root_user, uidhashentry(0));
- spin_unlock(&uidhash_lock);
+ spin_unlock_bh(&uidhash_lock);
return 0;
}
next reply other threads:[~2006-01-25 14:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-25 14:23 Ingo Molnar [this message]
2006-01-25 16:59 ` [patch, lock validator] fix uidhash_lock <-> RCU deadlock Daniel Walker
2006-01-29 13:55 ` Ingo Molnar
2006-01-26 11:13 ` Paul E. McKenney
2006-01-28 0:22 ` Linus Torvalds
2006-01-28 2:40 ` Paul E. McKenney
2006-01-30 4:14 ` Paul E. McKenney
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=20060125142307.GA5427@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@us.ibm.com \
--cc=torvalds@osdl.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;
as well as URLs for NNTP newsgroup(s).