diff options
author | Johannes Berg <johannes@sipsolutions.net> | 2009-09-12 03:03:15 +0000 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2009-09-14 17:02:50 -0700 |
commit | d136f1bd366fdb7e747ca7e0218171e7a00a98a5 (patch) | |
tree | cee39b3249c36aba4b765cae6d9d3579c9f10a2d /drivers/md/raid0.c | |
parent | 8be8057e72d7d319f8e97b26e16de8021fe63988 (diff) |
genetlink: fix netns vs. netlink table locking
Since my commits introducing netns awareness into
genetlink we can get this problem:
BUG: scheduling while atomic: modprobe/1178/0x00000002
2 locks held by modprobe/1178:
#0: (genl_mutex){+.+.+.}, at: [<ffffffff8135ee1a>] genl_register_mc_grou
#1: (rcu_read_lock){.+.+..}, at: [<ffffffff8135eeb5>] genl_register_mc_g
Pid: 1178, comm: modprobe Not tainted 2.6.31-rc8-wl-34789-g95cb731-dirty #
Call Trace:
[<ffffffff8103e285>] __schedule_bug+0x85/0x90
[<ffffffff81403138>] schedule+0x108/0x588
[<ffffffff8135b131>] netlink_table_grab+0xa1/0xf0
[<ffffffff8135c3a7>] netlink_change_ngroups+0x47/0x100
[<ffffffff8135ef0f>] genl_register_mc_group+0x12f/0x290
because I overlooked that netlink_table_grab() will
schedule, thinking it was just the rwlock. However,
in the contention case, that isn't actually true.
Fix this by letting the code grab the netlink table
lock first and then the RCU for netns protection.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/md/raid0.c')
0 files changed, 0 insertions, 0 deletions