Message ID | 20230620134624.99688-1-ilpo.jarvinen@linux.intel.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp3677241vqr; Tue, 20 Jun 2023 06:48:15 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7h5Ik/RhhnHZVk7Q4cbFbf1dVUGscLu/SxllAmzJMnwzxg72KZZmlAY1L+Ia+gBWGeW/q/ X-Received: by 2002:a17:902:f550:b0:1b5:ddf:b1b0 with SMTP id h16-20020a170902f55000b001b50ddfb1b0mr3624539plf.20.1687268895457; Tue, 20 Jun 2023 06:48:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687268895; cv=none; d=google.com; s=arc-20160816; b=HwBuH0fDHom7ngDz7/CdavaAaJ9yJndtXtPLHYp9PUX9URfCtmEu3OCHR/N3X4zydJ XJi3NK+7Ke/tpLG3BRiCvyd/A0w6CEdoN1BbVSwLAIPOLbaMwsSr30BhoV6oX6xPkHlS 5u1cLWxal2aKKIapWhLvhSuCEOZ/HYmjnSKvkCQwsQSCTy2Zpn2LZPgtq607uRPx0wGF gvc3c+BbaxA2t06orOpzoGqnvigOFeyC5hHYgBZGjKqa9OPLkL2p3VxihLcNgcHywj3R VRQPq1wjLo97qG5GbHDtptY3rWSiYh1/48a+GF9eu2BTTSAvKar1PQn9ccFVtnHM/Q5j PoVQ== 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; bh=buk8+jalcCLqIq3wZHGhYS52FHaw+mU5YpqO6HtE3Rg=; b=FQVuupxQndxFaxmcXINuUsJw0dNRSiUzkdCC7SadaytKERQObKEUJQZt/ALEtLJOdz 7y/k9GfJ2Q1/LjHyYWX9CbgPpVzianV1B8qY5DqeZ3XLVRqCu9tnc3oIJcxxP3RwQeYD U4HzbLdNCpbxZ1UY38KOFYB5CqMHpi/vpvqk4AvFqndr/Ov3xbj5lEjXTxOXcy4d2AgV XV9wPa2T8F0SYeBEuNlmxS957G+U6L8mPcLl+avnAsw40Bnc/dUgctwsVb6/hhyCWBTI at/XZsaQ3nl8yFVlShwfkY5QKnwPYC5bbLrz6Er0K2ygJzNIMkhswTiVH9Kvte/h/xpC 4ohQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kaXrJgwf; 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=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m14-20020a170902db0e00b001b3f9cedbb7si2013794plx.398.2023.06.20.06.48.02; Tue, 20 Jun 2023 06:48:15 -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=@intel.com header.s=Intel header.b=kaXrJgwf; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233099AbjFTNqx (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Tue, 20 Jun 2023 09:46:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233119AbjFTNqr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 20 Jun 2023 09:46:47 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F05AB170F; Tue, 20 Jun 2023 06:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687268796; x=1718804796; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=ylPye6jciyJjtMMCu96/PJn40ZJb9WI9dBE1nm/Ef0A=; b=kaXrJgwfmWNf69ZmREJh+/gbQzv8e5qzNC2jo5j2vAw4o59/umef2WCD wGiJXpzYCeqq1sjLYhC/SOABblvRxoBsAK5Vw7oO+3yrAJJxLkNlAFhrL H09MvXekToev0el/eMG2cyA4T9tFu4gdjsZLY2b0yQyjcmPcKk0Ondcqs qV5cwm7KihICZ9Em8FsiVwfhBzuFIwp8vPXtKU2xRBSl/ZON/44PGXKTd jcMMLuSNEE1OfG1YlFtpSL9gA4OosUnAIfKxInJ6yvZT5Rz+rbl7qt/k5 sDztcAazJ+pFLFJXkZQvTbD9/fA6gfa65qEkjcCoQUwUMiMJy28mUbltW g==; X-IronPort-AV: E=McAfee;i="6600,9927,10747"; a="362401245" X-IronPort-AV: E=Sophos;i="6.00,257,1681196400"; d="scan'208";a="362401245" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jun 2023 06:46:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10747"; a="827006532" X-IronPort-AV: E=Sophos;i="6.00,257,1681196400"; d="scan'208";a="827006532" Received: from eshaanan-mobl.ger.corp.intel.com (HELO ijarvine-mobl2.ger.corp.intel.com) ([10.252.61.137]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jun 2023 06:46:32 -0700 From: =?utf-8?q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com> To: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Rob Herring <robh@kernel.org>, =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= <kw@linux.com>, Emmanuel Grumbach <emmanuel.grumbach@intel.com>, "Rafael J . Wysocki" <rafael@kernel.org>, Heiner Kallweit <hkallweit1@gmail.com>, Lukas Wunner <lukas@wunner.de> Cc: LKML <linux-kernel@vger.kernel.org>, Dean Luick <dean.luick@cornelisnetworks.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, =?utf-8?q?Ilpo_J=C3=A4?= =?utf-8?q?rvinen?= <ilpo.jarvinen@linux.intel.com> Subject: [PATCH v3 00/10] PCI: Improve PCIe Capability RMW concurrency control Date: Tue, 20 Jun 2023 16:46:14 +0300 Message-Id: <20230620134624.99688-1-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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?1769229669617952799?= X-GMAIL-MSGID: =?utf-8?q?1769229669617952799?= |
Series |
PCI: Improve PCIe Capability RMW concurrency control
|
|
Message
Ilpo Järvinen
June 20, 2023, 1:46 p.m. UTC
PCI Express Capability RMW accessors don't properly protect against concurrent access. Link Control Register is written by a number of things in the kernel in a RMW fashion without any concurrency control. This could in the unlucky case lead to losing one of the updates. One of the most obvious path which can race with most of the other LNKCTL RMW operations seems to be ASPM policy sysfs write which triggers LNKCTL update. Similarly, Root Control Register can be concurrently accessed by AER and PME. Make pcie_capability_clear_and_set_word() (and other RMW accessors that call it) to use a per device spinlock to protect the RMW operations to the Capability Registers that require locking. Convert open-coded LNKCTL RMW operations to use pcie_capability_clear_and_set_word() to benefit from the locking. There's also a related series which improves ASPM service driver and device driver coordination by removing out-of-band ASPM state management from device drivers (which will remove some of the code fragments changed by this series but it has higher regression potential which is why it seems prudent to do these changes in two steps): https://lore.kernel.org/linux-pci/20230602114751.19671-1-ilpo.jarvinen@linux.intel.com/T/#t v3: - Split link retraining change off from ASPM patch & reorder it earlier - Adjust changelog to take into account the move of link retraining code into PCI core and no longer refer to ASPM (currently in pci/enumeration branch) - based on top of pci/main v2: - Keep the RMW ops caller API the same - Make pcie_capability_clear_and_set_word() a wrapper that uses locked/unlocked variant based on the capability reg - Extracted LNKCTL2 changes out from this series to keep this purely a series which fixes something (LNKCTL2 RMW lock is necessary only when PCIe BW control is introduced). - Added Fixes tags (it's a bit rathole but yeah, they're there now). - Renamed cap_lock to pcie_cap_lock - Changed ath1* to clear the ASPMC field before setting it Ilpo Järvinen (10): PCI: Add locking to RMW PCI Express Capability Register accessors PCI: Make link retraining use RMW accessors for changing LNKCTL PCI: pciehp: Use RMW accessors for changing LNKCTL PCI/ASPM: Use RMW accessors for changing LNKCTL drm/amdgpu: Use RMW accessors for changing LNKCTL drm/radeon: Use RMW accessors for changing LNKCTL net/mlx5: Use RMW accessors for changing LNKCTL wifi: ath11k: Use RMW accessors for changing LNKCTL wifi: ath12k: Use RMW accessors for changing LNKCTL wifi: ath10k: Use RMW accessors for changing LNKCTL drivers/gpu/drm/amd/amdgpu/cik.c | 36 +++++------------- drivers/gpu/drm/amd/amdgpu/si.c | 36 +++++------------- drivers/gpu/drm/radeon/cik.c | 36 +++++------------- drivers/gpu/drm/radeon/si.c | 37 +++++------------- .../ethernet/mellanox/mlx5/core/fw_reset.c | 9 +---- drivers/net/wireless/ath/ath10k/pci.c | 9 +++-- drivers/net/wireless/ath/ath11k/pci.c | 10 +++-- drivers/net/wireless/ath/ath12k/pci.c | 10 +++-- drivers/pci/access.c | 20 ++++++++-- drivers/pci/hotplug/pciehp_hpc.c | 12 ++---- drivers/pci/pcie/aspm.c | 38 ++++++++----------- drivers/pci/probe.c | 1 + include/linux/pci.h | 34 ++++++++++++++++- 13 files changed, 128 insertions(+), 160 deletions(-)
Comments
+Cc: Jonas Jonas, might be interesting material in scope of Marvell WiFi PM flow. Also shows that some WiFi chips disable ASPM which might be good to have on Marvell as well. On Tue, Jun 20, 2023 at 04:46:14PM +0300, Ilpo Järvinen wrote: > PCI Express Capability RMW accessors don't properly protect against > concurrent access. Link Control Register is written by a number of > things in the kernel in a RMW fashion without any concurrency control. > This could in the unlucky case lead to losing one of the updates. One > of the most obvious path which can race with most of the other LNKCTL > RMW operations seems to be ASPM policy sysfs write which triggers > LNKCTL update. Similarly, Root Control Register can be concurrently > accessed by AER and PME. > > Make pcie_capability_clear_and_set_word() (and other RMW accessors that > call it) to use a per device spinlock to protect the RMW operations to > the Capability Registers that require locking. Convert open-coded > LNKCTL RMW operations to use pcie_capability_clear_and_set_word() to > benefit from the locking. > > There's also a related series which improves ASPM service driver and > device driver coordination by removing out-of-band ASPM state > management from device drivers (which will remove some of the code > fragments changed by this series but it has higher regression > potential which is why it seems prudent to do these changes in two > steps): > https://lore.kernel.org/linux-pci/20230602114751.19671-1-ilpo.jarvinen@linux.intel.com/T/#t