All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liao, Chang" <liaochang1@huawei.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: <srivatsa.bhat@linux.vnet.ibm.com>, <linux-pm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cpufreq: Fix the race condition while updating the transition_task of policy
Date: Tue, 29 Aug 2023 14:17:30 +0800	[thread overview]
Message-ID: <b3c61d8a-d52d-3136-fbf0-d1de9f1ba411@huawei.com> (raw)
In-Reply-To: <CAJZ5v0iGikZ=JSA5Nyx5Dc4QunSC5BObNO5yzQh44UYjrtRKYg@mail.gmail.com>

Hi, Rafael

在 2023/8/28 16:58, Rafael J. Wysocki 写道:
> On Mon, Aug 28, 2023 at 10:52 AM Viresh Kumar <viresh.kumar@linaro.org> 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.

I agree, unless the transition_ongoing and transition_task fields are updated
atomically, there is always a window where inconsistency can occur in the policy
structure.

-- 
BR
Liao, Chang

  reply	other threads:[~2023-08-29  6:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-26  9:58 [PATCH] cpufreq: Fix the race condition while updating the transition_task of policy Liao Chang
2023-08-28  7:23 ` Viresh Kumar
2023-08-28  8:29   ` Liao, Chang
2023-08-28  8:52     ` Viresh Kumar
2023-08-28  8:58       ` Rafael J. Wysocki
2023-08-29  6:17         ` Liao, Chang [this message]
2023-08-28  9:29       ` Liao, Chang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b3c61d8a-d52d-3136-fbf0-d1de9f1ba411@huawei.com \
    --to=liaochang1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.