On 22-07-15, 01:15, Rafael J. Wysocki wrote:
So the problem is that the cpu_is_offline(cpu) check in cpufreq_add_dev() matches two distinct cases: (1) the CPU was not present before and it is just being hot-added and (2) the CPU is initially offline, but present, and this is the first time its device is registered. In the first case we can expect that the CPU will become online shortly (although that is not guaranteed too), but in the second case that very well may not happen.
Yeah.
We need to be able to distinguish between those two cases and your patch does that, but I'm not sure if this really is the most straightforward way to do it.
Maybe yeah. I will take another look into that after considering Russell's input.
I'm also unsure why you're changing the removal code paths. Is there any particular failure scenario you're concerned about?
The same issue is present here too. The problem was that cpu_offline() check was getting hit for a CPU that is present in related_cpus mask. While allocating/freeing the policy, we create links for all related_cpus and the cpu_offline() check was adding/removing the link again.