Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1364671pxj; Fri, 21 May 2021 12:20:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIYiJ3uYeLCWTS4f3Nhv4kMmwbxhjhnU1weqPVI3c65e0jjAQyeBdyxeAvzoQd0v03mYq1 X-Received: by 2002:a05:6e02:130e:: with SMTP id g14mr363907ilr.74.1621624820505; Fri, 21 May 2021 12:20:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621624820; cv=none; d=google.com; s=arc-20160816; b=bAX2IYLF/VsrLPwSPz6rfjw3iNg+zUOzunE0aFhdTMN6N4r6pnl0t9RgV1Iy5vLdso LUmlHXjfneoNzj9y4U5APIT7euhqfc2MuwrctApr2bAiBZB6IhRTekyyGBMwWd+YfRhf evyoW0Hki58jUgRQMgG1AlBRx8S4487ykwSbIlWeGHgG856z4d7YXaNm6fNO1bEWZxWg AtUHmYOwx511Q8UL3h8ob/EGqdQCtd/HMD8ANojQ+B3bkszUuvX429xFqIA7xmaFcHF1 5h3zkTkLGH4yfxv2xor9ILV1xYwsm/zgn77BkcYm6yYL59cN39DxmXm6fc9LOKr1TkbF cU3Q== 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=8clB6TpIVCho94JnVEq2KjWI71LnxqVBb8WHhQLjztY=; b=Wn7ibuwh1oUFHb3huNzb6dwlSQ6gqqpq5CMmniiroGPwE/jzwdCcwKA3ckFpm0HRg4 EaMq6e7gXsvp+oMFed3nneTbEubPsGSdJWQ9bu+kKEk+x8qcQ4kK2B1HkbUyLv9HzW8J q6h74/Yp9Z96woRJECTZWf8cy3LzT4y6lCAQF6geFgZCAiSZYIfAZnS2q+J8GXTIe5Nv fj+fowzp3qDysjuZRfz6AyUG4D6vig+0SBlx1PoZklu6adzOit/SCHzDFZ/xAoVttYVN 5R7U9CFcxmsAGFbKF/2L48M7romnn2tPspbfKs7LcKgZlkt0ib/7jz2x+tCjddbsNYWd LEmQ== 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 i10si6070297iog.60.2021.05.21.12.20.06; Fri, 21 May 2021 12:20:20 -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 S237075AbhETTPM (ORCPT + 99 others); Thu, 20 May 2021 15:15:12 -0400 Received: from mail-oi1-f175.google.com ([209.85.167.175]:42831 "EHLO mail-oi1-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236992AbhETTPJ (ORCPT ); Thu, 20 May 2021 15:15:09 -0400 Received: by mail-oi1-f175.google.com with SMTP id c196so9223341oib.9; Thu, 20 May 2021 12:13:47 -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=8clB6TpIVCho94JnVEq2KjWI71LnxqVBb8WHhQLjztY=; b=aDcEqrqwJRjem8UTJUdeImTvhaTiNy/kjgwnW+oMNIRoRgOZtmxXNAPDQEb2SsYclq o/lTYvbTomRFAxJwHzCUod9aP+PftJnbtNWlYKEEoUptbAVRZ4W9eeKWe1Va4evCJy2f EiouwYzA3TisTwltDFlC50frclXwhSeFiAiLpmDU2VNIaihxAMXQeIarUfnygSH58COM Wxn1rT+Ld/qLiMcBAaBeGSANkvh308vhZE27W470R7fTavcVvb5O0gTVlaDihB07pins tWZ3vWr4+cxlQFItAsHyHWGDiEtt18HeZNRSw65bqamOrfJodL1x7G0MuE+qz1QsiDTm BVuQ== X-Gm-Message-State: AOAM530IWdOQ/PiUVgrz++3cSCFRCGJ21z/aDKRZ9cjRK74skor0VR1w lDcTEcxuVsqa7FAPsAyynYv6rlmYrRk17+C+S+w= X-Received: by 2002:aca:1910:: with SMTP id l16mr4152216oii.69.1621538027288; Thu, 20 May 2021 12:13:47 -0700 (PDT) MIME-Version: 1.0 References: <20210519210253.3578025-1-andy.shevchenko@gmail.com> In-Reply-To: <20210519210253.3578025-1-andy.shevchenko@gmail.com> From: "Rafael J. Wysocki" Date: Thu, 20 May 2021 21:13:36 +0200 Message-ID: Subject: Re: [PATCH v1 1/1] ACPI: utils: Fix reference counting in for_each_acpi_dev_match() To: Andy Shevchenko Cc: "Rafael J. Wysocki" , Daniel Scally , ACPI Devel Maling List , Linux Kernel Mailing List , Linux Media Mailing List , "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" , "Rafael J. Wysocki" , Len Brown , Yong Zhi , Sakari Ailus , Bingbu Cao , Tianshu Qiu , Mauro Carvalho Chehab , Robert Moore , Erik Kaneda Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 19, 2021 at 11:19 PM Andy Shevchenko wrote: > > Currently it's possible to iterate over the dangling pointer in case the device > suddenly disappears. This may happen becase callers put it at the end of a loop. > > Instead, let's move that call inside acpi_dev_get_next_match_dev(). Not really. > Fixes: 803abec64ef9 ("media: ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver") > Fixes: bf263f64e804 ("media: ACPI / bus: Add acpi_dev_get_next_match_dev() and helper macro") > Cc: Daniel Scally > Cc: Sakari Ailus > Signed-off-by: Andy Shevchenko > --- > drivers/acpi/utils.c | 5 +---- > drivers/media/pci/intel/ipu3/cio2-bridge.c | 8 +++----- > include/acpi/acpi_bus.h | 5 ----- > 3 files changed, 4 insertions(+), 14 deletions(-) > > diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c > index 3b54b8fd7396..ccfc484dbffd 100644 > --- a/drivers/acpi/utils.c > +++ b/drivers/acpi/utils.c > @@ -846,10 +846,6 @@ EXPORT_SYMBOL(acpi_dev_present); > * Return the next match of ACPI device if another matching device was present > * at the moment of invocation, or NULL otherwise. > * > - * FIXME: The function does not tolerate the sudden disappearance of @adev, e.g. > - * in the case of a hotplug event. That said, the caller should ensure that > - * this will never happen. > - * > * The caller is responsible for invoking acpi_dev_put() on the returned device. > * > * See additional information in acpi_dev_present() as well. > @@ -866,6 +862,7 @@ acpi_dev_get_next_match_dev(struct acpi_device *adev, const char *hid, const cha > match.hrv = hrv; > > dev = bus_find_device(&acpi_bus_type, start, &match, acpi_dev_match_cb); > + acpi_dev_put(adev); What's the point? The caller may as well put it after this returns, can't it? And what if the caller still wants to do something with adev after this returns? > return dev ? to_acpi_device(dev) : NULL; > } > EXPORT_SYMBOL(acpi_dev_get_next_match_dev); The original changelog is somewhat unclear. It should say that it is required to reference-count the start-point device before passing it to this function, but beyond that I don't see a bug here. > diff --git a/drivers/media/pci/intel/ipu3/cio2-bridge.c b/drivers/media/pci/intel/ipu3/cio2-bridge.c > index e8511787c1e4..477417261b6e 100644 > --- a/drivers/media/pci/intel/ipu3/cio2-bridge.c > +++ b/drivers/media/pci/intel/ipu3/cio2-bridge.c > @@ -178,13 +178,11 @@ static int cio2_bridge_connect_sensor(const struct cio2_sensor_config *cfg, > > if (bridge->n_sensors >= CIO2_NUM_PORTS) { > dev_err(&cio2->dev, "Exceeded available CIO2 ports\n"); > - cio2_bridge_unregister_sensors(bridge); > ret = -EINVAL; > - goto err_out; > + goto err_put_adev; > } > > sensor = &bridge->sensors[bridge->n_sensors]; > - sensor->adev = adev; > strscpy(sensor->name, cfg->hid, sizeof(sensor->name)); > > ret = cio2_bridge_read_acpi_buffer(adev, "SSDB", > @@ -214,6 +212,7 @@ static int cio2_bridge_connect_sensor(const struct cio2_sensor_config *cfg, > goto err_free_swnodes; > } > > + sensor->adev = acpi_dev_get(adev); > adev->fwnode.secondary = fwnode; > > dev_info(&cio2->dev, "Found supported sensor %s\n", > @@ -227,8 +226,7 @@ static int cio2_bridge_connect_sensor(const struct cio2_sensor_config *cfg, > err_free_swnodes: > software_node_unregister_nodes(sensor->swnodes); > err_put_adev: > - acpi_dev_put(sensor->adev); > -err_out: > + acpi_dev_put(adev); > return ret; > } > > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h > index 3a82faac5767..bff6a11bb21f 100644 > --- a/include/acpi/acpi_bus.h > +++ b/include/acpi/acpi_bus.h > @@ -698,11 +698,6 @@ acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv); > * @hrv: Hardware Revision of the device, pass -1 to not check _HRV > * > * The caller is responsible for invoking acpi_dev_put() on the returned device. > - * > - * FIXME: Due to above requirement there is a window that may invalidate @adev > - * and next iteration will use a dangling pointer, e.g. in the case of a > - * hotplug event. That said, the caller should ensure that this will never > - * happen. > */ > #define for_each_acpi_dev_match(adev, hid, uid, hrv) \ > for (adev = acpi_dev_get_first_match_dev(hid, uid, hrv); \ > -- > 2.31.1 >