Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp306655pxu; Tue, 6 Oct 2020 06:59:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmbyes1RsAfmmqDmxwjDDamSF6QKJqHZQUXyfFGrfx+3ruKPnBgfiPF7AVfcr7373YnE7P X-Received: by 2002:a50:c05b:: with SMTP id u27mr5446948edd.290.1601992776299; Tue, 06 Oct 2020 06:59:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601992776; cv=none; d=google.com; s=arc-20160816; b=NZkvNCrrNRVKBaLwsk2eLBiBBCcyBQ3HVAfnPdaNmBcszlL9Jq64bLupWfXU5qhbS9 AFuTvZd7FOWSTTWECLNd7ZK25CTB0hBJXf7ntyQEExJD9aBpX0OooyNwCs7z3BHr3vFe T4hrQVd0M9dnTmJjsqMJE2Rbi3y8vC6Ugx4XoRcEb69IHTTc9ELTc6E6zjNYZhvVPkFR suMHcOVNK8JnpUYYiCZhdyHPIgLLKB/DBguUH+1ryEE2gSnnFdKdAY/tg+WcSoOPXtdx CVDRCQHd6klfCEH9jXvet/p6iemhuQqzM9ydVS80bUWm18TyE/RLnz+EIR78EgDJozQc mrIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=X1lgbO0KN64aF6ELTrDTiOq+HH8RynZOzp1I+2Xq3iQ=; b=eBbLCp+ccuozZsL4rMwaL4nDUST8Tr4bIhR3/wg3q+ZzdVlj1A4eyqhlK8kWlAA7P7 96+3dW1/lVhLouSC4zF9R8gs31JEq6iLAd0gohPO5Rhh9/6NO1PYS1AXxsRk2GJ4QdDW xY1ZIYRWASHWCiAa/TN5lnH86bZRebZcSBaT0dbom1tMvmviygFKF1vyswsatlnu2n76 qdUV4UNAaI+tnhUjEMOojNBI4zh3w0bLkUgsPjhpuNXLz8PzczpMCcjrDRxAUI7Y6RWO FDx3LAwrXbi+4yWaBQZFGsGH6Qdlxxqbo7NJ+Y0J13wVbYNJVt/ROCZe0DIhDs/yEOWa mYhQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v6si2480424edt.456.2020.10.06.06.59.12; Tue, 06 Oct 2020 06:59:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726060AbgJFN50 (ORCPT + 99 others); Tue, 6 Oct 2020 09:57:26 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:34947 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725902AbgJFN5Z (ORCPT ); Tue, 6 Oct 2020 09:57:25 -0400 Received: by mail-ot1-f66.google.com with SMTP id s66so12354488otb.2; Tue, 06 Oct 2020 06:57:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X1lgbO0KN64aF6ELTrDTiOq+HH8RynZOzp1I+2Xq3iQ=; b=YJC3Ek+wl9J5yVxvEwgrtYwijFlZ7wnAElOBciaVdvKX4IKihexzZfnqaABJJCkq2K vTZgpLvxCBIuzFCwCeZOAgp/rBS5Qoh0EOgibiET35GlqsdMu/19nKwDQmD/UuniRI2x oQqYwsV0ukHOcfDsnaE2mxSJHrbXn3G6q0QgM6sgY+2IAPv9hYUSHOrmLvtdBtFrGpqD wDa7Z8PSuoOoIVskk0/MaDa17DMla808HkZqgBjc/U57im3lKDRo7QKAnsOaFcjrf76d 5wMuTKtiH71w65INZ6XZUtwntHjCpbkLHLuQ4BD+9sEB0wLVwJ0IJDVLDSKaCbbssbP+ 1yHg== X-Gm-Message-State: AOAM530vRR4JWQzam9mVvvVpcfmVEYayzYRp+24NfVSVtUz0Hj9VKQA3 tiszj8id9uTbCuQszm+R1GY0MGpCqcDmrvYTmUsDZOPH X-Received: by 2002:a9d:734f:: with SMTP id l15mr3185667otk.260.1601992644679; Tue, 06 Oct 2020 06:57:24 -0700 (PDT) MIME-Version: 1.0 References: <7155888.fM3j0pV3QS@kreacher> In-Reply-To: <7155888.fM3j0pV3QS@kreacher> From: "Rafael J. Wysocki" Date: Tue, 6 Oct 2020 15:57:13 +0200 Message-ID: Subject: Re: [PATCH] cpufreq: stats: Add memory barrier to store_reset() To: Viresh Kumar Cc: LKML , Linux PM , "Rafael J. Wysocki" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 6, 2020 at 1:59 PM Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > There is nothing to prevent the CPU or the compiler from reordering > the writes to stats->reset_time and stats->reset_pending in > store_reset(), in which case the readers of stats->reset_time may see > a stale value. Moreover, on 32-bit arches the write to reset_time > cannot be completed in one go, so the readers of it may see a > partially updated value in that case. > > To prevent that from happening, add a write memory barrier between > the writes to stats->reset_time and stats->reset_pending in > store_reset(). > > Fixes: 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()") > Signed-off-by: Rafael J. Wysocki > --- > > I couldn't convince myself that it was OK to leave the code as it was. > > linux-next material. > > --- > drivers/cpufreq/cpufreq_stats.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > Index: linux-pm/drivers/cpufreq/cpufreq_stats.c > =================================================================== > --- linux-pm.orig/drivers/cpufreq/cpufreq_stats.c > +++ linux-pm/drivers/cpufreq/cpufreq_stats.c > @@ -99,6 +99,13 @@ static ssize_t store_reset(struct cpufre > * avoid races. > */ > WRITE_ONCE(stats->reset_time, get_jiffies_64()); > + /* > + * The memory barrier below is to prevent the readers of reset_time from > + * seeing a stale or partially updated value. Note that they both access > + * reset_time only if reset_pending is 1, so corresponding read barriers > + * are not needed. I'm taking this back after double-checking memory-barriers.txt. Will send a v2. > + */ > + smp_wmb(); > WRITE_ONCE(stats->reset_pending, 1); > > return count; > > >