Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp934475pxj; Wed, 16 Jun 2021 17:40:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZcN3CMpCK0WEw2SmQ4kTCz5HK1HHaPc296V9DZSgZQYT7tgTuXAo2AkhD++wYySrKRzvH X-Received: by 2002:a92:7510:: with SMTP id q16mr1498787ilc.291.1623890408578; Wed, 16 Jun 2021 17:40:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623890408; cv=none; d=google.com; s=arc-20160816; b=Jd6WwIBCEozP24LBHjqjm/O+8D9MCwTzRt4A+2CeyWtUZfNaGWkxCwCfBCNryFyX00 j9wgF9qQIEdKtyPCIXxrzvAAbmC4plZTRZi39fftDiEmAyX2w7bDiUDbupkxv83Yj3De olkXKB3/WMKN/K3t4LSt5QWXu/vr/YCbcEcNHr/Ge5kDTDNuxVSxsjruIL6Qyr/6fH4r atzZKk95Gh5eO+k0lzKZAq3IrRAeNzjROZkN+IEr7IjAMxk107pUC6hflEtf7Z66Fh8x kypCBbzFnepZ08NqLXEIDAnfayT/ubPJAsHLaLNybccOG+LAHYQkcUq+U48zLLrXG4Ws U1+A== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=1LD2I6yddEWVtgNL4f+IvXH4ocbPNvFLjj8l26v2vok=; b=RpPXjNPK4nXwZ9Ee6k2qdTHYwg/X88a9tqTL1gbhlq+4FEx/KuVHq2NjrrZSZAdHs2 GcTK824AQE7o1b0ZmwSRnNAWg/Pp41AZBY52mwROJfigtHfp7RwjniYAM+sOO0d4e0ru LKk5DSusZxQRVEZGp6huFFrn2yBgiC7+TiYC0pZEPPDrGp6rOqPAJFyx84LocxcwxW6K XXKuaeoI/Gy87kNZAedsz6FqDpWr2+Ue7h0u+sde4M1L2NM//KW3xbFZuURPcnv0FIZH nZPtee92IqAJjonbdvQf7kbcircrry6GZMGSiPifmqYnAPwqW+L/masItdvnSNh9NHNq MYEg== 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 x19si3810748ioa.74.2021.06.16.17.39.49; Wed, 16 Jun 2021 17:40:08 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231442AbhFPSCn (ORCPT + 99 others); Wed, 16 Jun 2021 14:02:43 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:59646 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230291AbhFPSCl (ORCPT ); Wed, 16 Jun 2021 14:02:41 -0400 Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 2.1.0) id f6a21bd901818967; Wed, 16 Jun 2021 20:00:33 +0200 Received: from kreacher.localnet (89-64-81-4.dynamic.chello.pl [89.64.81.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by v370.home.net.pl (Postfix) with ESMTPSA id D3971669966; Wed, 16 Jun 2021 20:00:32 +0200 (CEST) From: "Rafael J. Wysocki" To: Linux ACPI Cc: LKML , Hans de Goede Subject: [PATCH v2 5/5] ACPI: scan: Fix race related to dropping dependencies Date: Wed, 16 Jun 2021 20:00:32 +0200 Message-ID: <11783109.O9o76ZdvQC@kreacher> In-Reply-To: <3070024.5fSG56mABF@kreacher> References: <3140195.44csPzL39Z@kreacher> <3070024.5fSG56mABF@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-CLIENT-IP: 89.64.81.4 X-CLIENT-HOSTNAME: 89-64-81-4.dynamic.chello.pl X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfedvledguddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqnecuggftrfgrthhtvghrnhepvdejlefghfeiudektdelkeekvddugfeghffggeejgfeukeejleevgffgvdeluddtnecukfhppeekledrieegrdekuddrgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeekledrieegrdekuddrgedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqedprhgtphhtthhopehlihhnuhigqdgrtghpihesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehhuggvghhovgguvgesrhgvughhrghtrdgtohhm X-DCC--Metrics: v370.home.net.pl 1024; Body=3 Fuz1=3 Fuz2=3 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki If acpi_add_single_object() runs concurrently with respect to acpi_scan_clear_dep() which deletes a dependencies list entry where the device being added is the consumer, the device's dep_unmet counter may not be updated to reflect that change. Namely, if the dependencies list entry is deleted right after calling acpi_scan_dep_init() and before calling acpi_device_add(), acpi_scan_clear_dep() will not find the device object corresponding to the consumer device ACPI handle and it will not update its dep_unmet counter to reflect the deletion of the list entry. Consequently, the dep_unmet counter of the device will never become zero going forward which may prevent it from being completely enumerated. To address this problem, modify acpi_add_single_object() to run acpi_tie_acpi_dev(), to attach the ACPI device object created by it to the corresponding ACPI namespace node, under acpi_dep_list_lock along with acpi_scan_dep_init() whenever the latter is called. Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede --- -> v2: * Fix memory leak spotted by Hans. * Add the R-by tag from Hans. --- drivers/acpi/scan.c | 50 ++++++++++++++++++++++++++++++++------------------ 1 file changed, 32 insertions(+), 18 deletions(-) Index: linux-pm/drivers/acpi/scan.c =================================================================== --- linux-pm.orig/drivers/acpi/scan.c +++ linux-pm/drivers/acpi/scan.c @@ -657,16 +652,12 @@ static int acpi_tie_acpi_dev(struct acpi return 0; } -int acpi_device_add(struct acpi_device *device, - void (*release)(struct device *)) +int __acpi_device_add(struct acpi_device *device, + void (*release)(struct device *)) { struct acpi_device_bus_id *acpi_device_bus_id; int result; - result = acpi_tie_acpi_dev(device); - if (result) - return result; - /* * Linkage * ------- @@ -755,6 +746,17 @@ err_unlock: return result; } +int acpi_device_add(struct acpi_device *adev, void (*release)(struct device *)) +{ + int ret; + + ret = acpi_tie_acpi_dev(adev); + if (ret) + return ret; + + return __acpi_device_add(adev, release); +} + /* -------------------------------------------------------------------------- Device Enumeration -------------------------------------------------------------------------- */ @@ -1681,14 +1683,10 @@ static void acpi_scan_dep_init(struct ac { struct acpi_dep_data *dep; - mutex_lock(&acpi_dep_list_lock); - list_for_each_entry(dep, &acpi_dep_list, node) { if (dep->consumer == adev->handle) adev->dep_unmet++; } - - mutex_unlock(&acpi_dep_list_lock); } void acpi_device_add_finalize(struct acpi_device *device) @@ -1707,6 +1705,7 @@ static int acpi_add_single_object(struct acpi_handle handle, int type, bool dep_init) { struct acpi_device *device; + bool release_dep_lock = false; int result; device = kzalloc(sizeof(struct acpi_device), GFP_KERNEL); @@ -1720,16 +1719,31 @@ static int acpi_add_single_object(struct * this must be done before the get power-/wakeup_dev-flags calls. */ if (type == ACPI_BUS_TYPE_DEVICE || type == ACPI_BUS_TYPE_PROCESSOR) { - if (dep_init) + if (dep_init) { + mutex_lock(&acpi_dep_list_lock); + /* + * Hold the lock until the acpi_tie_acpi_dev() call + * below to prevent concurrent acpi_scan_clear_dep() + * from deleting a dependency list entry without + * updating dep_unmet for the device. + */ + release_dep_lock = true; acpi_scan_dep_init(device); - + } acpi_scan_init_status(device); } acpi_bus_get_power_flags(device); acpi_bus_get_wakeup_device_flags(device); - result = acpi_device_add(device, acpi_device_release); + result = acpi_tie_acpi_dev(device); + + if (release_dep_lock) + mutex_unlock(&acpi_dep_list_lock); + + if (!result) + result = __acpi_device_add(device, acpi_device_release); + if (result) { acpi_device_release(&device->dev); return result;