From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9BF3C83F17 for ; Tue, 29 Aug 2023 06:18:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232518AbjH2GSG (ORCPT ); Tue, 29 Aug 2023 02:18:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229618AbjH2GRh (ORCPT ); Tue, 29 Aug 2023 02:17:37 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D57E184; Mon, 28 Aug 2023 23:17:33 -0700 (PDT) Received: from kwepemd100002.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4RZcZB1PJjzNn9H; Tue, 29 Aug 2023 14:13:54 +0800 (CST) Received: from [10.67.110.108] (10.67.110.108) by kwepemd100002.china.huawei.com (7.221.188.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1258.23; Tue, 29 Aug 2023 14:17:30 +0800 Message-ID: Date: Tue, 29 Aug 2023 14:17:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: Re: [PATCH] cpufreq: Fix the race condition while updating the transition_task of policy To: "Rafael J. Wysocki" , Viresh Kumar CC: , , References: <20230826095836.1138608-1-liaochang1@huawei.com> <20230828072347.ly23mbptu3yw4zkv@vireshk-i7> <20230828085248.sz6aljr5aln7j435@vireshk-i7> From: "Liao, Chang" In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.110.108] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemd100002.china.huawei.com (7.221.188.184) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Rafael 在 2023/8/28 16:58, Rafael J. Wysocki 写道: > On Mon, Aug 28, 2023 at 10:52 AM Viresh Kumar 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