Re: About CPU hot-plug stress test failed in cpufreq driver

[Anson Huang <anson.huang@nxp.com>]

From Anson's iPhone 6


> 在 2019年12月9日，19:23，Rafael J. Wysocki <rafael@kernel.org> 写道：
> 
>> On Mon, Dec 9, 2019 at 11:57 AM Anson Huang <anson.huang@nxp.com> wrote:
>> 
>> Forgot to mentioned that below patch on v5.4 can easily reproduce the panic() on our platforms which I think is unexpected, as the policy->cpus already be updated after governor stop, but still try to have irq work queued on it.
>> 
>> static void dbs_update_util_handler(struct update_util_data *data, u64 time, unsigned int flags)
>> +       if (!cpumask_test_cpu(smp_processor_id(), policy_dbs->policy->cpus))
>> +               panic("...irq work on offline cpu %d\n", smp_processor_id());
>>        irq_work_queue(&policy_dbs->irq_work);
> 
> Yes, that is unexpected.
> 
> In cpufreq_offline(), we have:
> 
>    down_write(&policy->rwsem);
>    if (has_target())
>        cpufreq_stop_governor(policy);
> 
>    cpumask_clear_cpu(cpu, policy->cpus);
> 
> and cpufreq_stop_governor() calls policy->governor->stop(policy) which
> is cpufreq_dbs_governor_stop().
> 
> That calls gov_clear_update_util(policy_dbs->policy) first, which
> invokes cpufreq_remove_update_util_hook() for each CPU in policy->cpus
> and synchronizes RCU, so after that point none of the policy->cpus is
> expected to run dbs_update_util_handler().
> 
> policy->cpus is updated next and the governor is started again with
> the new policy->cpus.  Because the offline CPU is not there, it is not
> expected to run dbs_update_util_handler() again.
> 
> Do you only get the original error when one of the CPUs goes back online?

No, sometimes I also got this error during a CPU is being offline.

But the point is NOT that dbs_update_util_handler() called during governor stop, it is that this function is running on a CPU which already finish the governor stop function, I thought the original expectation is that this function ONLY be executed on the CPU which needs scaling frequency? Is this correct? v4.19 follows this expectation while v5.4 is NOT. 

The only thing I can image is the changes in kernel/sched/ folder cause this difference, but I still need more time to figure out what changes cause it, if you have any suggestion, please advise, thanks!

Anson