On Fri, Dec 22, 2006 at 02:44:58AM -0800, Andrew Morton wrote: > On Fri, 22 Dec 2006 16:07:24 +0530 > Gautham R Shenoy <[EMAIL PROTECTED]> wrote: > > > While we are at this per-subsystem cpuhotplug "locking", here's a > > proposal that might put an end to the workqueue deadlock woes. > > Oleg is working on some patches which will permit us to cancel or wait upon > a particular work_struct, rather than upon all pending work_structs. >
Oh! I was refering to the other set of workqueue deadlock woes. The ones caused when subsystems (like cpufreq) try to create/destroy workqueue from the cpuhotplug callback path. Creation/destruction of workqueue requires us to take workqueue_mutex, which would have already been taken during CPU_LOCK_ACQUIRE. More often than not, the cpu hotplug protection that we need is while accessing either cpu_online_map OR one of it's persubsystem mirrors like policy->cpus. So it makes more sense to have all the persubsystem mutexes held only during the cpu-hotplug operation (i.e stop_machine_run and __cpu_up) and release them immediately after sending notifications to update the persubsystem online_cpu map. Thanks and Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - 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/