Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp488196pxb; Thu, 14 Jan 2021 10:37:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJz1lerByRCDD6zjNUuBhz1/yUBp7ZEQ7sd+LeaK371ttTLjy7Fe/qcAxqtxOV5pUc7IwZpV X-Received: by 2002:a17:906:ce43:: with SMTP id se3mr2067857ejb.377.1610649444482; Thu, 14 Jan 2021 10:37:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610649444; cv=none; d=google.com; s=arc-20160816; b=eWNZVu1A0vR9nFdx7kuLVg2sWGHBJdReTlgCGFmq1Ng4RudkiY1+YX2ymDtGglewO1 YBIJlJnaqFqq5plgVFOr4lxcJegItA9Yhx3RlL/OUrrsvKfErjeuRhitrm2mvI9hze34 Ap/7cv2lrSytQuo/hOYrD/EXVuDhVjiOxi9S5nUfJdYY9hceptvrsfr0sSY1zikfrXKt dQ5VWY6lE0y6HuaRK8VoCjSdSbjU2EhQrdKCdswSzRBY5NxWa1ptuKyjgVtz9VDLGBRu RfjY1z+yAXqSWqbyXDhR+Csz7elFAyu4hMuADAxIlhaot7b6PAtX18lJwQQCWC9TGU6j BLqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=Xvlih4UBe2OtxfIwA0Urm6ZKoywYsqneYXDz2GIIZLQ=; b=f9Lla+o31McIo6AkIX1PU1tIF/Xibofe/DJcw+N5CU8N+HGOD989Ar+fX6Urmhff4/ I1lf7KinasZDQmGjnzw3s8XLSUl+cG7RSBK67KeVAWgfNOhVnG4M9FpSKkscPx24W1UF m975bxqYZQ0yBq/l0672twt/rjEIedqo4MaYEWOlMcXc8Mspr6KTL/mUFGofrTg8WRIT IX+wLLTtsOSimcL/UYM00BRm3qFPCzO6WFhUG0nXKyWd3cBMJuIs1I+X6oPjQWd+IpuW AU+T7lPFnnxqkmgUlUlGyXH+bnFaFW3C4qBmH0QsPskflfq4/x4JQGgYctqfEu5i0xmt mX8g== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t6si2575972ejr.116.2021.01.14.10.37.00; Thu, 14 Jan 2021 10:37:24 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729314AbhANSfJ (ORCPT + 99 others); Thu, 14 Jan 2021 13:35:09 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:58970 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726066AbhANSfI (ORCPT ); Thu, 14 Jan 2021 13:35:08 -0500 Received: from 89-64-81-33.dynamic.chello.pl (89.64.81.33) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.537) id 8df65316e316c48e; Thu, 14 Jan 2021 19:34:24 +0100 From: "Rafael J. Wysocki" To: Linux ACPI Cc: LKML , Zhang Rui , Linux PM , Stephen Berman , Sebastian Andrzej Siewior Subject: [PATCH] ACPI: thermal: Do not call acpi_thermal_check() directly Date: Thu, 14 Jan 2021 19:34:22 +0100 Message-ID: <3391226.KRKnzuvfpg@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki Calling acpi_thermal_check() from acpi_thermal_notify() directly is problematic if _TMP triggers Notify () on the thermal zone for which it has been evaluated (which happens on some systems), because it causes a new acpi_thermal_notify() invocation to be queued up every time and if that takes place too often, an indefinite number of pending work items may accumulate in kacpi_notify_wq over time. Besides, it is not really useful to queue up a new invocation of acpi_thermal_check() if one of them is pending already. For these reasons, rework acpi_thermal_notify() to queue up a thermal check instead of calling acpi_thermal_check() directly and only allow one thermal check to be pending at a time. Moreover, only allow one acpi_thermal_check_fn() instance at a time to run thermal_zone_device_update() for one thermal zone and make it return early if it sees other instances running for the same thermal zone. While at it, fold acpi_thermal_check() into acpi_thermal_check_fn(), as it is only called from there after the other changes made here. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208877 Reported-by: Stephen Berman Diagnosed-by: Sebastian Andrzej Siewior Signed-off-by: Rafael J. Wysocki --- drivers/acpi/thermal.c | 46 +++++++++++++++++++++++++++++++++------------- 1 file changed, 33 insertions(+), 13 deletions(-) Index: linux-pm/drivers/acpi/thermal.c =================================================================== --- linux-pm.orig/drivers/acpi/thermal.c +++ linux-pm/drivers/acpi/thermal.c @@ -174,6 +174,8 @@ struct acpi_thermal { struct thermal_zone_device *thermal_zone; int kelvin_offset; /* in millidegrees */ struct work_struct thermal_check_work; + struct mutex thermal_check_lock; + refcount_t thermal_check_count; }; /* -------------------------------------------------------------------------- @@ -495,14 +497,6 @@ static int acpi_thermal_get_trip_points( return 0; } -static void acpi_thermal_check(void *data) -{ - struct acpi_thermal *tz = data; - - thermal_zone_device_update(tz->thermal_zone, - THERMAL_EVENT_UNSPECIFIED); -} - /* sys I/F for generic thermal sysfs support */ static int thermal_get_temp(struct thermal_zone_device *thermal, int *temp) @@ -900,6 +894,12 @@ static void acpi_thermal_unregister_ther Driver Interface -------------------------------------------------------------------------- */ +static void acpi_queue_thermal_check(struct acpi_thermal *tz) +{ + if (!work_pending(&tz->thermal_check_work)) + queue_work(acpi_thermal_pm_queue, &tz->thermal_check_work); +} + static void acpi_thermal_notify(struct acpi_device *device, u32 event) { struct acpi_thermal *tz = acpi_driver_data(device); @@ -910,17 +910,17 @@ static void acpi_thermal_notify(struct a switch (event) { case ACPI_THERMAL_NOTIFY_TEMPERATURE: - acpi_thermal_check(tz); + acpi_queue_thermal_check(tz); break; case ACPI_THERMAL_NOTIFY_THRESHOLDS: acpi_thermal_trips_update(tz, ACPI_TRIPS_REFRESH_THRESHOLDS); - acpi_thermal_check(tz); + acpi_queue_thermal_check(tz); acpi_bus_generate_netlink_event(device->pnp.device_class, dev_name(&device->dev), event, 0); break; case ACPI_THERMAL_NOTIFY_DEVICES: acpi_thermal_trips_update(tz, ACPI_TRIPS_REFRESH_DEVICES); - acpi_thermal_check(tz); + acpi_queue_thermal_check(tz); acpi_bus_generate_netlink_event(device->pnp.device_class, dev_name(&device->dev), event, 0); break; @@ -1020,7 +1020,25 @@ static void acpi_thermal_check_fn(struct { struct acpi_thermal *tz = container_of(work, struct acpi_thermal, thermal_check_work); - acpi_thermal_check(tz); + + /* + * In general, it is not sufficient to check the pending bit, because + * subsequent instances of this function may be queued after one of them + * has started running (e.g. if _TMP sleeps). Avoid bailing out if just + * one of them is running, though, because it may have done the actual + * check some time ago, so allow at least one of them to block on the + * mutex while another one is running the update. + */ + if (!refcount_dec_not_one(&tz->thermal_check_count)) + return; + + mutex_lock(&tz->thermal_check_lock); + + thermal_zone_device_update(tz->thermal_zone, THERMAL_EVENT_UNSPECIFIED); + + refcount_inc(&tz->thermal_check_count); + + mutex_unlock(&tz->thermal_check_lock); } static int acpi_thermal_add(struct acpi_device *device) @@ -1052,6 +1070,8 @@ static int acpi_thermal_add(struct acpi_ if (result) goto free_memory; + refcount_set(&tz->thermal_check_count, 3); + mutex_init(&tz->thermal_check_lock); INIT_WORK(&tz->thermal_check_work, acpi_thermal_check_fn); pr_info(PREFIX "%s [%s] (%ld C)\n", acpi_device_name(device), @@ -1117,7 +1137,7 @@ static int acpi_thermal_resume(struct de tz->state.active |= tz->trips.active[i].flags.enabled; } - queue_work(acpi_thermal_pm_queue, &tz->thermal_check_work); + acpi_queue_thermal_check(tz); return AE_OK; }