Messages in this thread | | | Date | Sat, 20 Feb 2010 12:46:48 +0800 | Subject | Re: [2.6.33-rc5] Weird deadlock when shutting down | From | Américo Wang <> |
| |
On Fri, Feb 19, 2010 at 12:31 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Thu, 18 Feb 2010, Johannes Berg wrote: >> > >> > Basically, the machine deadlocks right after printing the following >> > when doing a shutdown: >> > >> > halt/4071 is trying to acquire lock: >> > (s_active){++++.+}, at: [<c0000000001ef868>] >> > .sysfs_addrm_finish+0x58/0xc0 >> > >> > but task is already holding lock: >> > (&per_cpu(cpu_policy_rwsem, cpu)){+.+.+.}, at: [<c0000000004cd6ac>] >> > .lock_policy_rwsem_write+0x84/0xf4 >> > >> > which lock already depends on the new lock. > > You don't have a full backtrace for these things? > > We've had lots of trouble with the cpu governors, and I suspect the > problem isn't new, but the lockdep warning is likely new (see commit > 846f99749ab68bbc7f75c74fec305de675b1a1bf: "sysfs: Add lockdep annotations > for the sysfs active reference"). > > So it is likely to be an old issue that (a) now gets warned about and (b) > might have had timing changes enough to trigger it. >
Right.
This is a real deadlock case found by lockdep added to s_active.
The problem is that we did kobject_put(&data->kobj) while holding policy_rwsem which is used to protect 'data'. It is not so easy to fix this, probably we need to do more work on cpufreq code.
Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |