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 E91F6C04E69 for ; Tue, 1 Aug 2023 18:39:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230323AbjHASjU (ORCPT ); Tue, 1 Aug 2023 14:39:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230376AbjHASjQ (ORCPT ); Tue, 1 Aug 2023 14:39:16 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2011426A2 for ; Tue, 1 Aug 2023 11:39:11 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-31759e6a4a1so5354965f8f.3 for ; Tue, 01 Aug 2023 11:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1690915149; x=1691519949; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8EFUJZW17T5kR5LxeUj/wsPffO8rw8SB5CP4M13sEbA=; b=nIDdrHwHHJSSZFT4EgZKRFPLGEaASm09NRdE8gzz78gej767WFTlvsJT7biZJvFRGP QnDAX4oyUAmzjyOYGm92j/snTZM/0cSx3xEl2Ksw1Im2uP6sm8RgVarCZ97ButDC8bry b08CRx/IKluU2ShZhUB3U7GZFkDYbl8OgArfBHn3Bm1dOtAbADZtQ4AEX4e7G66/7HqF dcQ2RDGNuWcI6xmQ6CM6zpH2DODt/8xMi6IazZPpee4uAxNhWsTWfRoLn8zl9dntictx MVdBZrlHIHOoyssnGA3naW48L+GCvPUsRPbFx7onUv05o1KWjQ8H6VlUmIcBu0jhJ61I 7afQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690915149; x=1691519949; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8EFUJZW17T5kR5LxeUj/wsPffO8rw8SB5CP4M13sEbA=; b=KpKQaUrVyur/VknDEZfhxjXqPEG/MT8xhjYPSn69fJSiXwSnhpuJPmD+BsvX1G+/kN 1X0uhowMK3ud31XEU1VrkuFazsA3T11YXFBcQopGckEimL/0BXaqLwy0zAfHQ+1rckzm q9/JcxSHKNarWMK1drCLfF6bcqQtNS5BXRykJFKxgtHq1cdMRX2ZhFtjLnVvjzkI9aBf Cf8VSrnJ+aFonEe0tG5R10Wm61V2j5oTc7fhR7tdH96vciuAetVGPuC0ox/Q9d45cEVQ /V/4DL81Azmxr4QQynoZ0MXdDtXw1A/jjSAgdm/+9jfyVkagxDAaf/Aa2t6dauSJX9Xd 4qGA== X-Gm-Message-State: ABy/qLbKJp1uT88h7hCOqZM7zuCEJkxnl9ig3ld04nQJdzO0nb3SmXYJ SMKeDaavAhKs/BzopZHI7/OY05UlfEPl3ltZVHA= X-Google-Smtp-Source: APBJJlGoXOK6T9ffOYXg6zcKFD+rEOM9ac7VCXjHLS2lYi4qWcVAesZsI5YXpRSR90jCU3rLLNxG1Q== X-Received: by 2002:a5d:5589:0:b0:317:70cb:4f58 with SMTP id i9-20020a5d5589000000b0031770cb4f58mr2858210wrv.63.1690915149541; Tue, 01 Aug 2023 11:39:09 -0700 (PDT) Received: from [192.168.10.46] (146725694.box.freepro.com. [130.180.211.218]) by smtp.googlemail.com with ESMTPSA id l18-20020a1c7912000000b003fe2bea77ccsm1435499wme.5.2023.08.01.11.39.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Aug 2023 11:39:08 -0700 (PDT) Message-ID: Date: Tue, 1 Aug 2023 20:39:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v3 5/8] ACPI: thermal: Hold thermal zone lock around trip updates Content-Language: en-US To: "Rafael J. Wysocki" , Linux ACPI Cc: LKML , Linux PM , Michal Wilczynski , Zhang Rui , Srinivas Pandruvada References: <13318886.uLZWGnKmhe@kreacher> <12254967.O9o76ZdvQC@kreacher> <7552439.EvYhyI6sBW@kreacher> From: Daniel Lezcano In-Reply-To: <7552439.EvYhyI6sBW@kreacher> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Hi Rafael, On 25/07/2023 14:16, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > There is a race condition between acpi_thermal_trips_update() and > acpi_thermal_check_fn(), because the trip points may get updated while > the latter is running which in theory may lead to inconsistent results. > For example, if two trips are updated together, using the temperature > value of one of them from before the update and the temperature value > of the other one from after the update may not lead to the expected > outcome. > > To address this, make acpi_thermal_trips_update() hold the thermal zone > lock across the entire update of trip points. As commented in patch 3/8, having a driver locking a thermal core structure is not right and goes to the opposite direction of the recent cleanups. Don't we have 2 race conditions: acpi_thermal_trips_update() + thermal_zone_device_check() acpi_thermal_trips_update() + acpi_thermal_trips_update() For the former, we can disable the thermal zone, update and then enable For the latter use a driver lock ? > While at it, change the acpi_thermal_trips_update() return data type > to void as that function always returns 0 anyway. > > Signed-off-by: Rafael J. Wysocki > --- > > v2 -> v3: No changes. > > v1 -> v2: > * Hold the thermal zone lock instead of thermal_check_lock around trip > point updates (this also helps to protect thermal_get_trend() from using > stale trip temperatures). > * Add a comment documenting the purpose of the locking. > * Make acpi_thermal_trips_update() void. > > --- > drivers/acpi/thermal.c | 21 ++++++++++++++++----- > 1 file changed, 16 insertions(+), 5 deletions(-) > > Index: linux-pm/drivers/acpi/thermal.c > =================================================================== > --- linux-pm.orig/drivers/acpi/thermal.c > +++ linux-pm/drivers/acpi/thermal.c > @@ -190,7 +190,7 @@ static int acpi_thermal_get_polling_freq > return 0; > } > > -static int acpi_thermal_trips_update(struct acpi_thermal *tz, int flag) > +static void __acpi_thermal_trips_update(struct acpi_thermal *tz, int flag) > { > acpi_status status; > unsigned long long tmp; > @@ -398,17 +398,28 @@ static int acpi_thermal_trips_update(str > ACPI_THERMAL_TRIPS_EXCEPTION(flag, tz, "device"); > } > } > +} > > - return 0; > +static void acpi_thermal_trips_update(struct acpi_thermal *tz, int flag) > +{ > + /* > + * The locking is needed here to protect thermal_get_trend() from using > + * a stale passive trip temperature and to synchronize with the trip > + * temperature updates in acpi_thermal_check_fn(). > + */ > + thermal_zone_device_lock(tz->thermal_zone); > + > + __acpi_thermal_trips_update(tz, flag); > + > + thermal_zone_device_unlock(tz->thermal_zone); > } > > static int acpi_thermal_get_trip_points(struct acpi_thermal *tz) > { > - int i, ret = acpi_thermal_trips_update(tz, ACPI_TRIPS_INIT); > bool valid; > + int i; > > - if (ret) > - return ret; > + __acpi_thermal_trips_update(tz, ACPI_TRIPS_INIT); > > valid = tz->trips.critical.valid | > tz->trips.hot.valid | > > > -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog