Message ID | 20230427142901.3570536-1-alexander.stein@ew.tq-group.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp312146vqo; Thu, 27 Apr 2023 07:34:37 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7xWX1Yr3ixDi8iNX+aUVMjzZvZxz4MMWPaP8cFsVNaxA3DBZ4hjXSTxAC5P6ZH4bRv+ym3 X-Received: by 2002:a17:90a:2dc2:b0:23c:fa83:2a7d with SMTP id q2-20020a17090a2dc200b0023cfa832a7dmr2207303pjm.12.1682606076834; Thu, 27 Apr 2023 07:34:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682606076; cv=none; d=google.com; s=arc-20160816; b=sTH2ZgNero+rCyu3iOKMGRxzxj0DnV2dZOkzE6RNbyloio8oL2bzQDArS06C8GLYM7 WXR9IlJYKCAUts+z3NWQZZlMVyMvqCxMzqHlFk/qg6Julmsb+2WIe3gIzrKQk4GxQOXS AECfYjpzEKxn42Jqv7By/SWeM1Ta1y8BNcO0xDnhz/Jkga5pimmw17I+raa4LYND2iAH b25cnY3tgP5c+qG8dg4rVZQw40oSa3P3oYBqueHp/Lg+APfK3v/ndMqVEJPAxJ30INZI hSMfVZtbPZtMs5LJcf3i53onx3SsQG2OVklSSRW+/csjQiblL+clAED5SpWOKQPpq0MU AHSw== 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:dkim-signature:dkim-signature; bh=gDC05yJnrnxFiM5XBTdbnuSpAwRc7QmiD7yubr33lrw=; b=fZRwKQV7HmKjzFT6YhqOkgwm2TDzVyCUxJRfBRG9MgHv+YNs2Z6u+9MujOyV9IcxA6 ukY28jyiZq5KhOMLjTaKuZYbHeIV5JfVX2E2pQygTQbZ01tKMZCLr6X5WphwGJAe2CTh viwL4/y0ZA+C6xgyZzLk99Hij2wRm0IRuC1AqSYUoDjt6ohMpPOzuKPBBMJGp6ozdKCB IZbpAxdk3d3jbuffDxWA+FlHglgG2vYmAoV7O9r5CTX/b1RbKYovmdT+Vzunl6hUVgZb /XVQwEPwisaK/GgeRcOAhrX56JH6tCpZdiptRlBo9iwqWa4RK3j3tNmfwjDAkNB/hDgj b61g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tq-group.com header.s=key1 header.b=VlojAe6e; dkim=pass header.i=@tq-group.com header.s=key1 header.b=OeLCYW5H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tq-group.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lx10-20020a17090b4b0a00b0024b9ac5462csi13398567pjb.94.2023.04.27.07.34.19; Thu, 27 Apr 2023 07:34:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@tq-group.com header.s=key1 header.b=VlojAe6e; dkim=pass header.i=@tq-group.com header.s=key1 header.b=OeLCYW5H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tq-group.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244072AbjD0O3R (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Thu, 27 Apr 2023 10:29:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243711AbjD0O3O (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 27 Apr 2023 10:29:14 -0400 Received: from mx1.tq-group.com (mx1.tq-group.com [93.104.207.81]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86AE23583; Thu, 27 Apr 2023 07:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1682605752; x=1714141752; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=gDC05yJnrnxFiM5XBTdbnuSpAwRc7QmiD7yubr33lrw=; b=VlojAe6eGavB43APGf+xxlOO1/CmMlySs2khdb8mkD8nlRtpWVe2u9Xm ylL/X8WLlwP9GL7ia9GyJxFMbfsrRH5LsRxg6cFtY/nlYyP/ybxaoLnFV 84MkFUDIvrEgqtpi2Gz1b6d4Z4XYfM+if4+7EYoSgIZCXTYb4RZRbgZ69 v2GjlQeDFd7+52kjAHmPXZUTzftzI05JWGr8VF5fvoJJtDUZOFwPwt6dy 250vJD9znWx3VljQyVGl1See2b80R4RoM/A9UuVlcrWx8C/EtKbFoZP9l tbuYdCKvdrt9u65NJLakgHJ2hUWDo9O4f+aAD3hdqXvlGf4WiMxO6N/KY Q==; X-IronPort-AV: E=Sophos;i="5.99,230,1677538800"; d="scan'208";a="30607875" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 27 Apr 2023 16:29:08 +0200 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Thu, 27 Apr 2023 16:29:08 +0200 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Thu, 27 Apr 2023 16:29:08 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1682605748; x=1714141748; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=gDC05yJnrnxFiM5XBTdbnuSpAwRc7QmiD7yubr33lrw=; b=OeLCYW5HuNcKptNsYjf9i/CTOQbYTUA4Z+EMpPSK0MMLr6+McuEKGQTT 09XDqUv8O3r5u15fI7aTo0rd6ImysXMaf1+qxxLijpV8hjaVr6At4azER T/nO6ku/E9x1euOW9gaOeNW0ZFZ6fIff9+1PsgkAf+4iv8f9tuFxnazCn Y0LADPAgYCfJGhEKkcQJ6x9sZltE1wa+OGfZT/VNUH+eM58SgcfRZnS/8 2ZcVQ/YaSn9qMpuLlUF03Q5ErNpzyGu784s2L5xtdtS+LOKc1B30ZfGYZ FRH8iqPrRD8P2O8gmy6rVM+/lF6naHwexztzwiyGViF3ykv+RRwbSEb3x w==; X-IronPort-AV: E=Sophos;i="5.99,230,1677538800"; d="scan'208";a="30607873" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 27 Apr 2023 16:29:08 +0200 Received: from steina-w.tq-net.de (unknown [10.123.53.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by vtuxmail01.tq-net.de (Postfix) with ESMTPSA id 20979280056; Thu, 27 Apr 2023 16:29:08 +0200 (CEST) From: Alexander Stein <alexander.stein@ew.tq-group.com> To: Bjorn Helgaas <bhelgaas@google.com> Cc: Alexander Stein <alexander.stein@ew.tq-group.com>, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Korneliusz Osmenda <korneliuszo@gmail.com>, Oliver Neukum <oneukum@suse.com> Subject: [PATCH 0/3] PCI: Fix race condition upon sysfs init Date: Thu, 27 Apr 2023 16:28:58 +0200 Message-Id: <20230427142901.3570536-1-alexander.stein@ew.tq-group.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764340349594150785?= X-GMAIL-MSGID: =?utf-8?q?1764340349594150785?= |
Series |
PCI: Fix race condition upon sysfs init
|
|
Message
Alexander Stein
April 27, 2023, 2:28 p.m. UTC
Hi everyone, this series is a totally different approach for fixing the sysfs init race condition. The initial problem is stated at [1]. Previous proposals were rejected ([2] and [3]). Here is what's happening CPU 0 CPU 1 imx6_pcie_probe() dw_pcie_host_init() pci_host_probe() pci_scan_root_bus_bridge() pci_scan_child_bus_extend() pci_scan_slot() pci_scan_single_device() pci_device_add() pci_sysfs_init() device_add() sysfs_initialized = 1; bus_add_device() for_each_pci_dev() ... pci_create_sysfs_dev_files() pci_bus_add_devices() pci_bus_add_device() pci_create_sysfs_dev_files() Eventually calling pci_create_sysfs_dev_files() twice on the same pci_dev. It's a very tight window, deeper PCIe trees increase that window during host probe. Asynchronous PCIe host probe is a necessity (PROBE_PREFER_ASYNCHRONOUS). The first two patches are preparations for the last one actually fixing the race. As functions like pci_create_sysfs_dev_files() are called from externtal and internal to pci-sysfs, an internal version without checking for sysfs_initialized is required. For the fix a wait queue is introduced where all callers from external callsites (regarding pci-sysfs.c) are waiting until pci_sysfs_init initcall has finished and woken up all waiters. A subtlety is that within __pci_create_sysfs_dev_files the resource files (created by pci_sysfs_init) need to be removed, so they can be created again from pci_host_probe call. Best regards, Alexander Links: [1] https://bugzilla.kernel.org/show_bug.cgi?id=215515 [2] https://lore.kernel.org/linux-pci/20230316091540.494366-1-alexander.stein@ew.tq-group.com/ [3] https://lore.kernel.org/linux-pci/20230316103036.1837869-1-alexander.stein@ew.tq-group.com/ Alexander Stein (3): PCI/sysfs: sort headers alphabetically PCI/sysfs: create private functions for pci_create_legacy_files/pci_create_sysfs_dev_files PCI/sysfs: Fix sysfs init race condition drivers/pci/pci-sysfs.c | 87 +++++++++++++++++++++++++---------------- 1 file changed, 53 insertions(+), 34 deletions(-)
Comments
On Thu, Apr 27, 2023 at 04:28:58PM +0200, Alexander Stein wrote: > Hi everyone, > > this series is a totally different approach for fixing the sysfs init race > condition. The initial problem is stated at [1]. Previous proposals were > rejected ([2] and [3]). Here is what's happening > > > CPU 0 CPU 1 > > imx6_pcie_probe() > dw_pcie_host_init() > pci_host_probe() > pci_scan_root_bus_bridge() > pci_scan_child_bus_extend() > pci_scan_slot() > pci_scan_single_device() > pci_device_add() > pci_sysfs_init() device_add() > sysfs_initialized = 1; bus_add_device() > for_each_pci_dev() ... > pci_create_sysfs_dev_files() > pci_bus_add_devices() > pci_bus_add_device() > pci_create_sysfs_dev_files() > > Eventually calling pci_create_sysfs_dev_files() twice on the same pci_dev. > It's a very tight window, deeper PCIe trees increase that window during > host probe. Asynchronous PCIe host probe is a necessity > (PROBE_PREFER_ASYNCHRONOUS). > > The first two patches are preparations for the last one actually fixing > the race. As functions like pci_create_sysfs_dev_files() are called from > externtal and internal to pci-sysfs, an internal version without checking > for sysfs_initialized is required. > For the fix a wait queue is introduced where all callers from external > callsites (regarding pci-sysfs.c) are waiting until pci_sysfs_init > initcall has finished and woken up all waiters. > > A subtlety is that within __pci_create_sysfs_dev_files the resource files > (created by pci_sysfs_init) need to be removed, so they can be created > again from pci_host_probe call. I'll look at this in more detail, but if there's any way at all that we could get rid of pci_sysfs_init() completely and do this with static attributes or some other existing sysfs infrastructure, I would STRONGLY prefer it because that infrastructure has already solved this problem. Maybe that's impossible and we really need to make a one-off solution just for PCI, but ... I haven't been convinced yet. > Links: > [1] https://bugzilla.kernel.org/show_bug.cgi?id=215515 > [2] https://lore.kernel.org/linux-pci/20230316091540.494366-1-alexander.stein@ew.tq-group.com/ > [3] https://lore.kernel.org/linux-pci/20230316103036.1837869-1-alexander.stein@ew.tq-group.com/ > > Alexander Stein (3): > PCI/sysfs: sort headers alphabetically > PCI/sysfs: create private functions for > pci_create_legacy_files/pci_create_sysfs_dev_files > PCI/sysfs: Fix sysfs init race condition > > drivers/pci/pci-sysfs.c | 87 +++++++++++++++++++++++++---------------- > 1 file changed, 53 insertions(+), 34 deletions(-) > > -- > 2.34.1 >