[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21958338.EfDdHjke4D@kreacher>
Date: Tue, 18 Jul 2023 20:06:02 +0200
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Linux ACPI <linux-acpi@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linux PM <linux-pm@...r.kernel.org>,
Michal Wilczynski <michal.wilczynski@...el.com>,
Zhang Rui <rui.zhang@...el.com>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>
Subject: [PATCH v1 4/7] ACPI: thermal: Hold thermal_check_lock around trip updates
From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
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 thermal_check_lock
across the entire update of trip points.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
---
drivers/acpi/thermal.c | 4 ++++
1 file changed, 4 insertions(+)
Index: linux-pm/drivers/acpi/thermal.c
===================================================================
--- linux-pm.orig/drivers/acpi/thermal.c
+++ linux-pm/drivers/acpi/thermal.c
@@ -193,6 +193,8 @@ static int acpi_thermal_trips_update(str
struct acpi_handle_list devices;
bool valid = false;
int i;
+
+ mutex_lock(&tz->thermal_check_lock);
/* Critical Shutdown */
if (flag & ACPI_TRIPS_CRITICAL) {
@@ -395,6 +397,8 @@ static int acpi_thermal_trips_update(str
}
}
+ mutex_unlock(&tz->thermal_check_lock);
+
return 0;
}
Powered by blists - more mailing lists