On 09/04/13 17:26, Rafael J. Wysocki wrote: > On Wednesday, September 04, 2013 04:50:01 PM Stephen Boyd wrote: >> On 09/04/13 16:55, Rafael J. Wysocki wrote: >>> Well, I'm not sure when Viresh is going to be back. >>> >>> Srivatsa, can you please resend this patch with a proper changelog? >>> >> I haven't had a chance to try this out yet, but I was just thinking >> about this patch. How is it going to work? If one task opens the file >> and another task is taking down the CPU wouldn't we deadlock in the >> CPU_DOWN notifier waiting for the kobject to be released? Task 1 will >> grab the kobject reference and sleep on the hotplug mutex and task 2 >> will put the kobject and wait for the completion, but it won't happen. >> At least I think that's what would happen. > Do you mean the completion in sysfs_deactivate()? Yes, we can deadlock > there. I mean the complete in cpufreq_sysfs_release(). I don't think that will ever be called because the kobject is held by the task calling store() which is waiting on the hotplug lock to be released. > > Well, I guess the Srivatsa's patch may be salvaged by making it do a "trylock" > version of get_online_cpus(), but then I wonder if there's no better way. I think the real solution is to remove the kobject first if the CPU going down is the last user of that policy. Once the completion is done we can stop the governor and clean up state. For the case where there are still CPUs using the policy why can't we cancel that CPU's work and do nothing else? Even in the case where we have to move the cpufreq directory do we need to do a STOP/START/LIMITS sequence? I hope we can get away with just moving the directory and canceling that CPUs work then. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
