Re: [PATCH] cpufreq: Fix the race condition while updating the transition_task of policy

From: Rafael J. Wysocki
Date: Mon Aug 28 2023 - 04:59:52 EST


On Mon, Aug 28, 2023 at 10:52 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
>
> On 28-08-23, 16:29, Liao, Chang wrote:
> > Task B does not necessarily go to sleep when it calls wait_event(), it depends on
> > the condition to wait for evaluate false or not. So there is a small race window
> > where Task A already set 'transition_ongoing' to false and Task B can cross wait_event()
> > immediately.
> >
> > wait_event:
> > do {
> > might_sleep();
> > if (condition) // !transition_ongoing
> > break;
> > __wait_event();
> > };
> >
> > I hope I do not miss something important in the code above.
>
> > Yes, if the CPU uses weak memroy model, it is possible for the instructions to be reordered.
> > therefore, it is a good idea to insert an smb() between these two lines if there is race here.
>
> Maybe it would be better to do this instead ?
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 6b52ebe5a890..f11b01b25e8d 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -455,8 +455,10 @@ void cpufreq_freq_transition_end(struct cpufreq_policy *policy,
> policy->cur,
> policy->cpuinfo.max_freq);
>
> + spin_lock(&policy->transition_lock);
> policy->transition_ongoing = false;
> policy->transition_task = NULL;
> + spin_unlock(&policy->transition_lock);
>
> wake_up(&policy->transition_wait);
> }
>
> --

I was about to suggest the same thing.

wake_up() is a full memory barrier only if it actually wakes up a task
and if it doesn't do that, without the locking the other task may see
a state in which transition_ongoing is false already and
transition_task is still NULL regardless of the relative ordering of
the statements before the wake_up() call.