From patchwork Thu Dec 1 04:01:24 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolu Lu X-Patchwork-Id: 28190 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp71953wrr; Wed, 30 Nov 2022 20:41:41 -0800 (PST) X-Google-Smtp-Source: AA0mqf5IjP2tV6E3P6JDzjA54zBZGdn/f5IpIo1i2KPxLXV8RAAmQNfqGQ/3M3Y+4o7Hcn3d6j6E X-Received: by 2002:a17:906:1412:b0:7a0:3313:a775 with SMTP id p18-20020a170906141200b007a03313a775mr45131384ejc.474.1669869701042; Wed, 30 Nov 2022 20:41:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669869701; cv=none; d=google.com; s=arc-20160816; b=kQozdRp7cVz6+r95KysMDlmImARrwyTGWoKH94IisHUjpBA8xmulQsdFcysC0yVWEg 1uBcXswj89A4TT9u6lJos91ceS54CM72vJ/Z7INAkpIlbe7Jlrv1OXarKqEtollqTsiA dJUtzokexNG22P+0OX685HL994WOEDcrm/tnowLfm3scTWvW2l6PrEAb/MuI4NteLe1T KaZJzZ42MBLwrYQUsfD58Pod64224E8Bd9fdlQwgD1hISPtXvUnvAssQ0119NFE+LPGb TIHGWImSl3oJhNTIHmVTPK5LAElV/syNwRlDY9Z91EkmPnxjYMLKVYqXCekrIcBBxIR9 mRmw== 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 :dkim-signature; bh=fIp09suBZe3XniJMGmTtS1f+DrX2zUB+5xa/KiCOL0g=; b=cpWNTDsm9esgVg1k4hyvIFlFuHarsZ/g6Mu+Ae591ZT62yfi6Xv5zsE4KJE/Mehxsu N9rePn7n5ANFMH3tkXAcegM780ny/5c7YAFam0nJWB6zDqkwz53QfkCv+NYAoIkXmSPY t2wopWnNbCbg/EV/e+yj3eWfZujelbkozDzLqGpclCAuAzI/7qBqRdZHJWI/tk9RUaiz 5RUqUdEyP9nOtihl70xLFimEQbcyvOAQLHJ6iX4rDQEF4jyu2SlceBw7gu2s0LBRTcWT gA1bemTpHImq6Qrl8GSaz3sEU9AuLx32xVNIEzLfmCHwYEal35hE4PVXoT3q4CNbkXXK QMDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=OXUsdtJz; 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 o14-20020a170906974e00b007c0a9cff536si2013025ejy.510.2022.11.30.20.41.18; Wed, 30 Nov 2022 20:41:41 -0800 (PST) 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=OXUsdtJz; 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 S229611AbiLAEI7 (ORCPT + 99 others); Wed, 30 Nov 2022 23:08:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229617AbiLAEIw (ORCPT ); Wed, 30 Nov 2022 23:08:52 -0500 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E1EE8EE7E for ; Wed, 30 Nov 2022 20:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669867730; x=1701403730; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=u5/DKb3gXHXITPU9e9Cfgq1VlJoRaQkY34dpdDM/E2k=; b=OXUsdtJzIyyUGu7fOwlNL555smAqVs3idlfHbZmXb/ZAZZkNq9G2thhL n8LDueeYliosq1TaiTKLEIv2DE5RjEWg4vVXdoACSwaxJlGmdxuXTt1Ei Ajxio0n0KPx2SaLUzXFfCbrtd4ctZpPMFf5X5ICFRkt4Cq9CCQY2AtKcu SEJN0gHf2PtOYm0cdl55HbNTkboao0aIMMuWMNxHzfsO5Xmbt4tPFT/2s NfyqSA60xf8+vv/PxWGr7R2lSsuZS3TcrQYU+4pFDwM2WQq0Pl+AEE4nw V8nnBWHQH1UswlXR2Yftb8zerUus/5xuCCLSYG7Ke+4//h2zSSB3V1D93 Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="377745729" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="377745729" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2022 20:08:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="707911655" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="707911655" Received: from allen-box.sh.intel.com ([10.239.159.48]) by fmsmga008.fm.intel.com with ESMTP; 30 Nov 2022 20:08:43 -0800 From: Lu Baolu To: Joerg Roedel Cc: Xiongfeng Wang , Yang Yingliang , Jacob Pan , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 1/4] iommu/vt-d: Add a fix for devices need extra dtlb flush Date: Thu, 1 Dec 2022 12:01:24 +0800 Message-Id: <20221201040127.1962750-2-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221201040127.1962750-1-baolu.lu@linux.intel.com> References: <20221201040127.1962750-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 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,SPF_HELO_NONE, SPF_NONE 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750985291493708270?= X-GMAIL-MSGID: =?utf-8?q?1750985291493708270?= From: Jacob Pan QAT devices on Intel Sapphire Rapids and Emerald Rapids have a defect in address translation service (ATS). These devices may inadvertently issue ATS invalidation completion before posted writes initiated with translated address that utilized translations matching the invalidation address range, violating the invalidation completion ordering. This patch adds an extra device TLB invalidation for the affected devices, it is needed to ensure no more posted writes with translated address following the invalidation completion. Therefore, the ordering is preserved and data-corruption is prevented. Device TLBs are invalidated under the following six conditions: 1. Device driver does DMA API unmap IOVA 2. Device driver unbind a PASID from a process, sva_unbind_device() 3. PASID is torn down, after PASID cache is flushed. e.g. process exit_mmap() due to crash 4. Under SVA usage, called by mmu_notifier.invalidate_range() where VM has to free pages that were unmapped 5. userspace driver unmaps a DMA buffer 6. Cache invalidation in vSVA usage (upcoming) For #1 and #2, device drivers are responsible for stopping DMA traffic before unmap/unbind. For #3, iommu driver gets mmu_notifier to invalidate TLB the same way as normal user unmap which will do an extra invalidation. The dTLB invalidation after PASID cache flush does not need an extra invalidation. Therefore, we only need to deal with #4 and #5 in this patch. #1 is also covered by this patch due to common code path with #5. Tested-by: Yuzhang Luo Reviewed-by: Ashok Raj Reviewed-by: Kevin Tian Signed-off-by: Jacob Pan Link: https://lore.kernel.org/r/20221130062449.1360063-1-jacob.jun.pan@linux.intel.com Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.h | 4 +++ drivers/iommu/intel/iommu.c | 69 +++++++++++++++++++++++++++++++++++-- drivers/iommu/intel/svm.c | 5 ++- 3 files changed, 75 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 92023dff9513..db9df7c3790c 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -623,6 +623,7 @@ struct device_domain_info { u8 pri_enabled:1; u8 ats_supported:1; u8 ats_enabled:1; + u8 dtlb_extra_inval:1; /* Quirk for devices need extra flush */ u8 ats_qdep; struct device *dev; /* it's NULL for PCIe-to-PCI bridge */ struct intel_iommu *iommu; /* IOMMU used by this device */ @@ -728,6 +729,9 @@ void qi_flush_piotlb(struct intel_iommu *iommu, u16 did, u32 pasid, u64 addr, void qi_flush_dev_iotlb_pasid(struct intel_iommu *iommu, u16 sid, u16 pfsid, u32 pasid, u16 qdep, u64 addr, unsigned int size_order); +void quirk_extra_dev_tlb_flush(struct device_domain_info *info, + unsigned long address, unsigned long pages, + u32 pasid, u16 qdep); void qi_flush_pasid_cache(struct intel_iommu *iommu, u16 did, u64 granu, u32 pasid); diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 996a8b5ee5ee..587eebe39820 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1396,6 +1396,24 @@ static void domain_update_iotlb(struct dmar_domain *domain) spin_unlock_irqrestore(&domain->lock, flags); } +/* + * The extra devTLB flush quirk impacts those QAT devices with PCI device + * IDs ranging from 0x4940 to 0x4943. It is exempted from risky_device() + * check because it applies only to the built-in QAT devices and it doesn't + * grant additional privileges. + */ +#define BUGGY_QAT_DEVID_MASK 0x494c +static bool dev_needs_extra_dtlb_flush(struct pci_dev *pdev) +{ + if (pdev->vendor != PCI_VENDOR_ID_INTEL) + return false; + + if ((pdev->device & 0xfffc) != BUGGY_QAT_DEVID_MASK) + return false; + + return true; +} + static void iommu_enable_pci_caps(struct device_domain_info *info) { struct pci_dev *pdev; @@ -1478,6 +1496,7 @@ static void __iommu_flush_dev_iotlb(struct device_domain_info *info, qdep = info->ats_qdep; qi_flush_dev_iotlb(info->iommu, sid, info->pfsid, qdep, addr, mask); + quirk_extra_dev_tlb_flush(info, addr, mask, PASID_RID2PASID, qdep); } static void iommu_flush_dev_iotlb(struct dmar_domain *domain, @@ -4490,9 +4509,10 @@ static struct iommu_device *intel_iommu_probe_device(struct device *dev) if (dev_is_pci(dev)) { if (ecap_dev_iotlb_support(iommu->ecap) && pci_ats_supported(pdev) && - dmar_ats_supported(pdev, iommu)) + dmar_ats_supported(pdev, iommu)) { info->ats_supported = 1; - + info->dtlb_extra_inval = dev_needs_extra_dtlb_flush(pdev); + } if (sm_supported(iommu)) { if (pasid_supported(iommu)) { int features = pci_pasid_features(pdev); @@ -4931,3 +4951,48 @@ static void __init check_tylersburg_isoch(void) pr_warn("Recommended TLB entries for ISOCH unit is 16; your BIOS set %d\n", vtisochctrl); } + +/* + * Here we deal with a device TLB defect where device may inadvertently issue ATS + * invalidation completion before posted writes initiated with translated address + * that utilized translations matching the invalidation address range, violating + * the invalidation completion ordering. + * Therefore, any use cases that cannot guarantee DMA is stopped before unmap is + * vulnerable to this defect. In other words, any dTLB invalidation initiated not + * under the control of the trusted/privileged host device driver must use this + * quirk. + * Device TLBs are invalidated under the following six conditions: + * 1. Device driver does DMA API unmap IOVA + * 2. Device driver unbind a PASID from a process, sva_unbind_device() + * 3. PASID is torn down, after PASID cache is flushed. e.g. process + * exit_mmap() due to crash + * 4. Under SVA usage, called by mmu_notifier.invalidate_range() where + * VM has to free pages that were unmapped + * 5. Userspace driver unmaps a DMA buffer + * 6. Cache invalidation in vSVA usage (upcoming) + * + * For #1 and #2, device drivers are responsible for stopping DMA traffic + * before unmap/unbind. For #3, iommu driver gets mmu_notifier to + * invalidate TLB the same way as normal user unmap which will use this quirk. + * The dTLB invalidation after PASID cache flush does not need this quirk. + * + * As a reminder, #6 will *NEED* this quirk as we enable nested translation. + */ +void quirk_extra_dev_tlb_flush(struct device_domain_info *info, + unsigned long address, unsigned long mask, + u32 pasid, u16 qdep) +{ + u16 sid; + + if (likely(!info->dtlb_extra_inval)) + return; + + sid = PCI_DEVID(info->bus, info->devfn); + if (pasid == PASID_RID2PASID) { + qi_flush_dev_iotlb(info->iommu, sid, info->pfsid, + qdep, address, mask); + } else { + qi_flush_dev_iotlb_pasid(info->iommu, sid, info->pfsid, + pasid, qdep, address, mask); + } +} diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c index 7d08eb034f2d..fe615c53479c 100644 --- a/drivers/iommu/intel/svm.c +++ b/drivers/iommu/intel/svm.c @@ -184,10 +184,13 @@ static void __flush_svm_range_dev(struct intel_svm *svm, return; qi_flush_piotlb(sdev->iommu, sdev->did, svm->pasid, address, pages, ih); - if (info->ats_enabled) + if (info->ats_enabled) { qi_flush_dev_iotlb_pasid(sdev->iommu, sdev->sid, info->pfsid, svm->pasid, sdev->qdep, address, order_base_2(pages)); + quirk_extra_dev_tlb_flush(info, address, order_base_2(pages), + svm->pasid, sdev->qdep); + } } static void intel_flush_svm_range_dev(struct intel_svm *svm, From patchwork Thu Dec 1 04:01:25 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolu Lu X-Patchwork-Id: 28184 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp62674wrr; Wed, 30 Nov 2022 20:09:13 -0800 (PST) X-Google-Smtp-Source: AA0mqf5GsV4UJHmOKL4Cru5b6HrLhc67GupmgjZU5nV4/l6N6zEM9NZW5rB08vwApQRRN+iWSMKH X-Received: by 2002:a17:902:b613:b0:188:f570:7bd6 with SMTP id b19-20020a170902b61300b00188f5707bd6mr45731574pls.97.1669867753184; Wed, 30 Nov 2022 20:09:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669867753; cv=none; d=google.com; s=arc-20160816; b=Ec8THK+EQGQp6I0hhQGfO/LJqSvdd36qSXtUUhEIFYk74HlqghV08odAA94QyrNwzV YiXzdVpjM/vlpQAYLw1SS6nn7hZmsOl+W4pbY2Ez2ad2fWJA4CVfkGwOroGoMfN0Qfwa cGfRqc1G0oIby/fYpDPil4QxDMqznuuDnIftks6zAmVnBsFSROowSoPCKD2v3vK2dlK2 QSCnb6z726frkdC3gMmnYXyQPI0/ZzlnzZ9ynKL5fSukcMokU2bX/Ew1PfsyxlcTYK2g DIGyJ7ampIL6gvFmnulKa8WGO52qHJdpTxoRvZkc70kPcDcjg2VxFyHkEC3sxF1U4bQA HjsQ== 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 :dkim-signature; bh=5Ww0UppS7eh3NW3UvrOtJnxOM7FAOY0bBSoExnpBdUI=; b=vuAE+4VltbzyafH2jiZtOsDVOvxrE5lkFDeuY/iv6ptr+4EK+fpuIw/utgkwjWRbIb ggW0g/Nz9vWIDmubBVaPz1L3vSq2tQhbRwOOK1txgmuOB7qp5kz9Y/mLN2KD+pTvjWhz kKH6ASBlkxbZtSNcg32d1DWLDkGAhqBAIRrNclF2wdHYm0TpND7ssw6UzIf1V8uy8k1Q PoD5M0V+lVB2y/fcwyFdn+sjrqFYUd3+JjDwVm4mah3x/lsu6YalbACthhwPVzbeGRGU qELE/jWPLC/RkoRm9tk+rmGCzDVSftmDIOzlJV+Xvo8QUJkFpq21LTel6OA+fLG33vOp C5WA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=j8CeyG5K; 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 i14-20020a17090332ce00b00186f035eda3si3522099plr.579.2022.11.30.20.09.00; Wed, 30 Nov 2022 20:09:13 -0800 (PST) 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=j8CeyG5K; 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 S229614AbiLAEIv (ORCPT + 99 others); Wed, 30 Nov 2022 23:08:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229608AbiLAEIt (ORCPT ); Wed, 30 Nov 2022 23:08:49 -0500 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32ECD77422 for ; Wed, 30 Nov 2022 20:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669867729; x=1701403729; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=r8ZxO0P+bgikDq55sQqKBRK6c8+nVfCJ+RSELC/xG0I=; b=j8CeyG5KAt9cIa5U7ewGh2jzdk9c6AcHHl/jvLGs3CSI2rswVfLix09x G7h/gUvh+xy56BYbP6+dwUooftNutv0wwhU80p3loMqFaPWLah5Pwp1Ox kxGRfWnIO0JlH92NMbzRpUTvvn5PIFfYWyJE9kSL9WJEacRv7S5GI87yc Umb38AlQABx97Sh0t/wHve8WeKFW8t9aIZVnQd/ASslshQYn1an+gDuCh D+0IGB7SH1qG1Lbzuy7rwAPwtg+P0FGVPUbdUnejII/ON9UJ8AZhAmEY9 Y0PPwdAgT5nUSggCjPtmFiNRlbkTL5tmNC0zdN+4AbhkvWyKq7+3F9c3E Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="377745747" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="377745747" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2022 20:08:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="707911656" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="707911656" Received: from allen-box.sh.intel.com ([10.239.159.48]) by fmsmga008.fm.intel.com with ESMTP; 30 Nov 2022 20:08:44 -0800 From: Lu Baolu To: Joerg Roedel Cc: Xiongfeng Wang , Yang Yingliang , Jacob Pan , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 2/4] iommu/vt-d: Fix PCI device refcount leak in prq_event_thread() Date: Thu, 1 Dec 2022 12:01:25 +0800 Message-Id: <20221201040127.1962750-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221201040127.1962750-1-baolu.lu@linux.intel.com> References: <20221201040127.1962750-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 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,SPF_HELO_NONE, SPF_NONE 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750983249350918351?= X-GMAIL-MSGID: =?utf-8?q?1750983249350918351?= From: Yang Yingliang As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrease the reference count by calling pci_dev_put(). So call pci_dev_put() after using the 'pdev' to avoid refcount leak. Besides, if the 'pdev' is null or intel_svm_prq_report() returns error, there is no need to trace this fault. Fixes: 06f4b8d09dba ("iommu/vt-d: Remove unnecessary SVA data accesses in page fault path") Suggested-by: Lu Baolu Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221119144028.2452731-1-yangyingliang@huawei.com Signed-off-by: Lu Baolu --- drivers/iommu/intel/svm.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c index fe615c53479c..03b25358946c 100644 --- a/drivers/iommu/intel/svm.c +++ b/drivers/iommu/intel/svm.c @@ -748,12 +748,16 @@ static irqreturn_t prq_event_thread(int irq, void *d) * If prq is to be handled outside iommu driver via receiver of * the fault notifiers, we skip the page response here. */ - if (!pdev || intel_svm_prq_report(iommu, &pdev->dev, req)) - handle_bad_prq_event(iommu, req, QI_RESP_INVALID); + if (!pdev) + goto bad_req; - trace_prq_report(iommu, &pdev->dev, req->qw_0, req->qw_1, - req->priv_data[0], req->priv_data[1], - iommu->prq_seq_number++); + if (intel_svm_prq_report(iommu, &pdev->dev, req)) + handle_bad_prq_event(iommu, req, QI_RESP_INVALID); + else + trace_prq_report(iommu, &pdev->dev, req->qw_0, req->qw_1, + req->priv_data[0], req->priv_data[1], + iommu->prq_seq_number++); + pci_dev_put(pdev); prq_advance: head = (head + sizeof(*req)) & PRQ_RING_MASK; } From patchwork Thu Dec 1 04:01:26 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolu Lu X-Patchwork-Id: 28188 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp70931wrr; Wed, 30 Nov 2022 20:38:05 -0800 (PST) X-Google-Smtp-Source: AA0mqf591YS2hzCkWgYwlvL6Qpns+x1XPUi/AKs9+BlE0gF8cKWzYfC4CffpPI8uzN/6VS0nitoI X-Received: by 2002:a17:90b:2d90:b0:212:ca73:4d6b with SMTP id sj16-20020a17090b2d9000b00212ca734d6bmr73587445pjb.16.1669869485157; Wed, 30 Nov 2022 20:38:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669869485; cv=none; d=google.com; s=arc-20160816; b=BREwADjNoz9jLn3uUAcQq6ZYoYPt3C+gHRx3Y2ntR03MOCwG+GtyvTTt5rHe7gsvn4 ufnftTJCaJyKOqmkeB3ME/7htkOgxKELWSYH2d2jLe3M1McUafKJF8PPSNo7rXpDKDHd OKSc3pODaUnfybQXMO40VjBW9wnCAjamkrIrMPV+TClWDAYOkyFkVaMGon88tuxZEDqH t7Xmp/ATAh6JHMkvEHDibZ/PVCQrWh8jfL5oZ+kPrvCBITd4W0vwkPGrwRRIYr89bsKS TLubz/b0Zk24UWetFexlEydQPw5KxKyu9XLqp+b3uCe8wXK/Tt5n2I61A9OiL7R5zLcZ ugCA== 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 :dkim-signature; bh=WpwZklKjSi3+4wZZ8Wx4CYl0hORMywiQGd2p+SthXCM=; b=QCF6rYE+xD1xiftYg29lz5m4nH/WpnYJhKYkmZGKXwelPZ1NX9mZsV4TQosr2ZG4CX FOjnkuNf47vv7aDmudceUqYB1+GZ6rHTljqRl//um5INangZR8U6RbdLVqwUaWc/L1sc /8UllP+Y4ALWJpPE5TAX0DRG2CvsW2vBpvYQVggLVoG0eiphUI8W6gCDaauJoHOMgrvi SmLrv848gCtd1gXHGXA8DGvFkDj4GuqngdvC127Yn5QwfxeUH82XT7WVPaij6JJAg5Pr SPwa+BPNZP3J8OQ+sw8KmeNfJAPkzifkcPBW45LcprQYEYYPFhjelDAWMJnsxFSXjaB+ QVuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cYdAk5GB; 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 u25-20020a634719000000b004774c91af0dsi3094702pga.841.2022.11.30.20.37.51; Wed, 30 Nov 2022 20:38:05 -0800 (PST) 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=cYdAk5GB; 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 S229690AbiLAEJG (ORCPT + 99 others); Wed, 30 Nov 2022 23:09:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229622AbiLAEIw (ORCPT ); Wed, 30 Nov 2022 23:08:52 -0500 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 461FC77400 for ; Wed, 30 Nov 2022 20:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669867731; x=1701403731; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kjh7d4AzSK7GzAYNGRKUHRiJpGxHBkXpSkEPbEmZzzE=; b=cYdAk5GBVHy2QQTZyuY6oBUQm7e9/Rfch6UQh3OOPr8d+9rHGXB2zY/s mp2lmZoLihTl4qeeSiaNwo+jQDUDw5GB4ULttKV8l9jEE89PSBnetVpX1 fOpHKLxYgu9kR4S5vjhl7t2UCXdvNpCgNPHb9/D+3psx8AvbwjwB25UsI Nm57TJ7cE5elHSDhbYmDbSrg2JbdN29YhuewK3gO8rJLrt1B00UUzQ9v/ XUFFiXeFPaHy78vp96e9R/bsVCNLax9BG9esU5Ekpu14ZmmcmX4OnWSl7 oVtXWE1Wema4GeRGtkfgF4+Ig78hieyOTndWwRxm8T4prl18gVI3vl/ku g==; X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="377745755" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="377745755" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2022 20:08:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="707911660" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="707911660" Received: from allen-box.sh.intel.com ([10.239.159.48]) by fmsmga008.fm.intel.com with ESMTP; 30 Nov 2022 20:08:46 -0800 From: Lu Baolu To: Joerg Roedel Cc: Xiongfeng Wang , Yang Yingliang , Jacob Pan , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 3/4] iommu/vt-d: Fix PCI device refcount leak in has_external_pci() Date: Thu, 1 Dec 2022 12:01:26 +0800 Message-Id: <20221201040127.1962750-4-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221201040127.1962750-1-baolu.lu@linux.intel.com> References: <20221201040127.1962750-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 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,SPF_HELO_NONE, SPF_NONE 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750985065220822168?= X-GMAIL-MSGID: =?utf-8?q?1750985065220822168?= From: Xiongfeng Wang for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() before 'return true' to avoid reference count leak. Fixes: 89a6079df791 ("iommu/vt-d: Force IOMMU on for platform opt in hint") Signed-off-by: Xiongfeng Wang Link: https://lore.kernel.org/r/20221121113649.190393-2-wangxiongfeng2@huawei.com Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 587eebe39820..5287efe247b1 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3873,8 +3873,10 @@ static inline bool has_external_pci(void) struct pci_dev *pdev = NULL; for_each_pci_dev(pdev) - if (pdev->external_facing) + if (pdev->external_facing) { + pci_dev_put(pdev); return true; + } return false; } From patchwork Thu Dec 1 04:01:27 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolu Lu X-Patchwork-Id: 28186 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp65612wrr; Wed, 30 Nov 2022 20:19:03 -0800 (PST) X-Google-Smtp-Source: AA0mqf5wrwKzEL4Jq5ltxXd/K7Nd/agrkp0agQe4/91keh2Ozu72GNsfag2rNhNvdS624kGpmklY X-Received: by 2002:a63:f308:0:b0:43b:ddc9:1d13 with SMTP id l8-20020a63f308000000b0043bddc91d13mr57661097pgh.284.1669868342838; Wed, 30 Nov 2022 20:19:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669868342; cv=none; d=google.com; s=arc-20160816; b=l603/NTygRr3dSPwss4OyhDTeoKpY9WMyLcUA54KrM5MzljWWifO2p2zKrlJ7DVwyo cQAWHhc462+Nr/7NZq1qdKQSge+bB2DwbNCXtU2gvXVPu+EhZBI5tWT51RBAVFET685y K5dg1/0f97sIFHlBpuN2zCiDjUT1S8r6kGQYqhcF/yeabohtRoZGjnAjefwemMSFsPVG jYrXsZeleYwvwtKtoOXegOjWtOmLl8m97624YCXXQvjsiFhGopbbehZx10sXiQrh77+P jqfr6kfYx7BjrFfgHitcE51uKanzTHrX8mKUPUjLb8gUNLZvpTfA3CulJN1epOaK0vma HzQg== 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 :dkim-signature; bh=8lQq3xHOoahTDBhnDkrNVkpv/4eXQeOK+e0TWQxwTXI=; b=nRxC8p3K7n5zEsNVjwQeM4lxiKPn+sWq5vVB7RaGRZBjKEFqQjJXQncOzLWIXYbBuL M9yE5nicgxRTEXJlYQ3VN/aOk+YPOsNVYN/zK5i9+AmW8T2SV5H8Xb3OpsxsoDrYeP9v 4TwMwCGTj7CQCKd2VNUAlKHWfTPcrmRS/wM8M4Rk92+rWFzquV0GobKJHurkvYn6v4b3 /8zZF5VOULqVjCpzImsPChUZR5XYcVSuW/wjnFbIJj7vhNsUuYfO6g892KWDzB4l1VVQ zbuDsM6sWwq4xPvVf4G5ZC7qtHNKQMiEfOJjKPIKdPz600fRzvDSQnzZiEc5wiaYQxv1 e7Gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="aZZq9ES/"; 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 j1-20020a056a00130100b005721983cbe7si3759162pfu.318.2022.11.30.20.18.35; Wed, 30 Nov 2022 20:19:02 -0800 (PST) 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="aZZq9ES/"; 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 S229682AbiLAEJD (ORCPT + 99 others); Wed, 30 Nov 2022 23:09:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229621AbiLAEIw (ORCPT ); Wed, 30 Nov 2022 23:08:52 -0500 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8885E77422 for ; Wed, 30 Nov 2022 20:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669867731; x=1701403731; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=yXwiYNvS9neESZJSKR531+MusOXMqiOrzDRp1zDx7kM=; b=aZZq9ES/lwJnKG8Rm8qMtCMnO8l/9QX5s/8rrHCf/1UiQmOJNGTUs3nh GWvJLfRE3QpQDdJHIGw9PrMsIoOrHvHmQbkjJbzbB3IjyeQTTlHrnpyu3 a6musvFkqH/jmAkDaaJ3hpOToAz5vUMSXXOrDS1BW5xmMpQXJYao/ORXF PMVb0c5Pn/7Xj1WJpv0AIST/iakYUvSeU4sDOnPlnYunLcjTWXH3hTk22 MfmHJ8rMl5AFmD5Oew6eSFNMmUT7XDTTPqTM5p/qDTmgmnrOy9nMA1R// buRmTK5X0IqamNmMrBx+jceKtxKU2nB8htH/NhcSXku435wMz25S03dT8 w==; X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="377745765" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="377745765" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2022 20:08:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="707911661" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="707911661" Received: from allen-box.sh.intel.com ([10.239.159.48]) by fmsmga008.fm.intel.com with ESMTP; 30 Nov 2022 20:08:48 -0800 From: Lu Baolu To: Joerg Roedel Cc: Xiongfeng Wang , Yang Yingliang , Jacob Pan , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 4/4] iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() Date: Thu, 1 Dec 2022 12:01:27 +0800 Message-Id: <20221201040127.1962750-5-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221201040127.1962750-1-baolu.lu@linux.intel.com> References: <20221201040127.1962750-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 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,SPF_HELO_NONE, SPF_NONE 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750983867815324584?= X-GMAIL-MSGID: =?utf-8?q?1750983867815324584?= From: Xiongfeng Wang for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak. Fixes: 2e4552893038 ("iommu/vt-d: Unify the way to process DMAR device scope array") Signed-off-by: Xiongfeng Wang Link: https://lore.kernel.org/r/20221121113649.190393-3-wangxiongfeng2@huawei.com Signed-off-by: Lu Baolu --- drivers/iommu/intel/dmar.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index 5a8f780e7ffd..bc94059a5b87 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -820,6 +820,7 @@ int __init dmar_dev_scope_init(void) info = dmar_alloc_pci_notify_info(dev, BUS_NOTIFY_ADD_DEVICE); if (!info) { + pci_dev_put(dev); return dmar_dev_scope_status; } else { dmar_pci_bus_add_dev(info);