Ashok Raj wrote:
> On Tue, May 30, 2006 at 03:39:47PM -0400, Dave Jones wrote:
>
> > So, that last part pretty highlights that we knew about this problem, and meant to
> > come back and fix it later. Surprise surprise, no one came back and fixed it.
> >
>
> There was another iteration after his, and currently we keep track of
> the owner in lock_cpu_hotplug()->__lock_cpu_hotplug(). So if we are in
> same thread context we dont acquire locks.
>
> if (lock_cpu_hotplug_owner != current) {
> if (interruptible)
> ret = down_interruptible(&cpucontrol);
> else
> down(&cpucontrol);
> }
>
>
> the lock and unlock kept track of the depth as well, so we know when to release
Can we please kill this recursive locking hack in the cpu hotplug code
in 2.6.18/soon? It's papering over the real problem, and I worry that
if it's allowed to sit there, other users will start to take
"advantage" of it. Perhaps, at the very least, cpufreq could be made
to handle this itself instead of polluting the core code...
> We didnt hear any better suggestions (from cpufreq folks), so we left it in
> that state (atlease the same thread doenst try to take the lock twice)
> that resulted in deadlocks earlier.
Fix (and document!) the ordering of lock acquisitions in cpufreq?
-
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]
