From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A0D8720E6E4; Wed, 16 Apr 2025 12:01:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744804914; cv=none; b=toZXGyobQSSJU5ESK9kp242HsTkPUp+kKDEnAhzHphIiRZdLsFciYefLbUAbc6sagBGqOUakJKHoeAduazny5kohLfDflUifYAOJHZiKEu3x47SH0clvkFbb2jK/6OcK8vV5pXY7wMx73Syuw7akVyzw2CgoYY/oJpIipkAEu7Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744804914; c=relaxed/simple; bh=61G4ZtYEDF4bwHv3JKZIAd75tAB7F5sVcNbZwmSNjpo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rpCSCqiJj9EclAuNoEmd/5RduBqb1BJE1huRP0SiSYpePEBiDyc5yw78aTRjJiWWKZmyDU6yMmQ9fNYQnn5JwRCW8hMJf8qBhWor+xHf1KPWM1sjt20QecroYFbeapiS7v+SMk55XB2CgE/JrDsdF6b1n2abHx22ikQ6DFJjMVI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BB4DC1595; Wed, 16 Apr 2025 05:01:48 -0700 (PDT) Received: from [10.1.35.42] (e127648.arm.com [10.1.35.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 225443F694; Wed, 16 Apr 2025 05:01:47 -0700 (PDT) Message-ID: Date: Wed, 16 Apr 2025 13:01:46 +0100 Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/6] cpufreq/sched: Explicitly synchronize limits_changed flag handling To: "Rafael J. Wysocki" , Linux PM Cc: LKML , Viresh Kumar , Srinivas Pandruvada , Mario Limonciello , Vincent Guittot , Sultan Alsawaf , Peter Zijlstra , Valentin Schneider , Ingo Molnar References: <6171293.lOV4Wx5bFT@rjwysocki.net> <3376719.44csPzL39Z@rjwysocki.net> Content-Language: en-US From: Christian Loehle In-Reply-To: <3376719.44csPzL39Z@rjwysocki.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/15/25 10:59, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The handling of the limits_changed flag in struct sugov_policy needs to > be explicitly synchronized to ensure that cpufreq policy limits updates > will not be missed in some cases. > > Without that synchronization it is theoretically possible that > the limits_changed update in sugov_should_update_freq() will be > reordered with respect to the reads of the policy limits in > cpufreq_driver_resolve_freq() and in that case, if the limits_changed > update in sugov_limits() clobbers the one in sugov_should_update_freq(), > the new policy limits may not take effect for a long time. > > Likewise, the limits_changed update in sugov_limits() may theoretically > get reordered with respect to the updates of the policy limits in > cpufreq_set_policy() and if sugov_should_update_freq() runs between > them, the policy limits change may be missed. > > To ensure that the above situations will not take place, add memory > barriers preventing the reordering in question from taking place and > add READ_ONCE() and WRITE_ONCE() annotations around all of the > limits_changed flag updates to prevent the compiler from messing up > with that code. > > Fixes: 600f5badb78c ("cpufreq: schedutil: Don't skip freq update when limits change") > Cc: 5.3+ # 5.3+ typo in the address here. I don't fully understand why we wouldn't want this in 6.15-rc already, even if the actual impact may be limited? > Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle >[snip]