Nick Piggin wrote:
Andrew Morton wrote:
- If a piece of kernel code is dealing with per-cpu data and cannot run
atomically then it should have its own cpu hotplug handlers anyway. It
is up to that code (ie: cpufreq) to provide its own locking against its
own CPU hotplug callback.
This still does not solve this cpufreq problem where it is trying to
take the same lock twice down the same call path. Whether it is the
lock_cpu_hotplug mutex or another one, the code must be just busted.
Err...
s/twice down the same call path/inverted with another lock
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
