From nobody Wed Dec 17 08:53:03 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0DF262066D4 for ; Wed, 19 Mar 2025 02:20:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742350842; cv=none; b=LhnzieAU11RkuHgC6k6txnKtSfia/ctQjl++LDaNXa56HzXkZH4f9/vDFmeHomi6YJVnL340J7inRwEq06JEj7vVmb/oXSnjxcCH6d5GT7O/iJD3WRCNxmHP1i7NJ0TO0sjGy0hkGPnmiLEMZ2GB1gFo8hktqspkiY1HetK3v8g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742350842; c=relaxed/simple; bh=TcFOaMBC3GdcjOyQV2RecoDfdc6RUJknTRvdya4AKys=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Wvh04ql0eOBTB7Hfdpxf3rHDgWmlBe4dpHeyICrWdlQYQU/tVXPdgYi/ffK3uYnBizkwERUL0fkr7QK/xRC1Pb6zlDIXEeua5ADveOuKA0ATmkNGYYoeOd1dzPN6tG2W5xuQhaBRPfV/j2xezr7TNUN3yXFgLmLeAGYrQt/VHsI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=VFe5GliK; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VFe5GliK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1742350841; x=1773886841; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=TcFOaMBC3GdcjOyQV2RecoDfdc6RUJknTRvdya4AKys=; b=VFe5GliKf6c4+U8vslI48O2WsyK0svSiDExCR8sQOwM8IF2cBHw6QC5n YmUL3YRtpjbzFPM7/twpfLcAG6Lk/EqqiBnZnpOwXnpSdOxO6u2vSPzoI QHGDPtegjpQC+Xlmy0QL1yDQGJlTFtdF0gHPlzNGfkWLRQ2R8KUshNPFx LHEcCN1RKlYHxW+EP08qZ2Ifwi4oYWpLRsQo+XNDwLme0Ay8o1NNicmib ZU0ADtJkFBZ0trS5XXG68aBBng6H1OoMfC1bEnVhzbIYbSIFzmke7PZsp XGJkx4Z6KQ4tOAA7r16wHKErliwEL0tp2Z37CDjpQCbFlWyC7plldHzVr Q==; X-CSE-ConnectionGUID: nhduTO9vSVaUjD9oCPiIAw== X-CSE-MsgGUID: BM7K1/ILQu+vlbiZFBCBCQ== X-IronPort-AV: E=McAfee;i="6700,10204,11377"; a="42693229" X-IronPort-AV: E=Sophos;i="6.14,258,1736841600"; d="scan'208";a="42693229" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2025 19:20:40 -0700 X-CSE-ConnectionGUID: zME7LeUqQ3updjLGzdwjTQ== X-CSE-MsgGUID: loUmRC3sQxqg7KwWaHBMDA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,258,1736841600"; d="scan'208";a="123372401" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa008.jf.intel.com with ESMTP; 18 Mar 2025 19:20:39 -0700 From: Lu Baolu To: Joerg Roedel Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 1/3] iommu/vt-d: Put IRTE back into posted MSI mode if vCPU posting is disabled Date: Wed, 19 Mar 2025 10:20:59 +0800 Message-ID: <20250319022101.1053133-2-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250319022101.1053133-1-baolu.lu@linux.intel.com> References: <20250319022101.1053133-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sean Christopherson Add a helper to take care of reconfiguring an IRTE to deliver IRQs to the host, i.e. not to a vCPU, and use the helper when an IRTE's vCPU affinity is nullified, i.e. when KVM puts an IRTE back into "host" mode. Because posted MSIs use an ephemeral IRTE, using modify_irte() puts the IRTE into full remapped mode, i.e. unintentionally disables posted MSIs on the IRQ. Fixes: ed1e48ea4370 ("iommu/vt-d: Enable posted mode for device MSIs") Cc: stable@vger.kernel.org Cc: Thomas Gleixner Cc: Jacob Pan Signed-off-by: Sean Christopherson Link: https://lore.kernel.org/r/20250315025135.2365846-2-seanjc@google.com Signed-off-by: Lu Baolu --- drivers/iommu/intel/irq_remapping.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/iommu/intel/irq_remapping.c b/drivers/iommu/intel/irq_= remapping.c index ad795c772f21..c495b533103f 100644 --- a/drivers/iommu/intel/irq_remapping.c +++ b/drivers/iommu/intel/irq_remapping.c @@ -1169,7 +1169,17 @@ static void intel_ir_reconfigure_irte_posted(struct = irq_data *irqd) static inline void intel_ir_reconfigure_irte_posted(struct irq_data *irqd)= {} #endif =20 -static void intel_ir_reconfigure_irte(struct irq_data *irqd, bool force) +static void __intel_ir_reconfigure_irte(struct irq_data *irqd, bool force_= host) +{ + struct intel_ir_data *ir_data =3D irqd->chip_data; + + if (ir_data->irq_2_iommu.posted_msi) + intel_ir_reconfigure_irte_posted(irqd); + else if (force_host || ir_data->irq_2_iommu.mode =3D=3D IRQ_REMAPPING) + modify_irte(&ir_data->irq_2_iommu, &ir_data->irte_entry); +} + +static void intel_ir_reconfigure_irte(struct irq_data *irqd, bool force_ho= st) { struct intel_ir_data *ir_data =3D irqd->chip_data; struct irte *irte =3D &ir_data->irte_entry; @@ -1182,10 +1192,7 @@ static void intel_ir_reconfigure_irte(struct irq_dat= a *irqd, bool force) irte->vector =3D cfg->vector; irte->dest_id =3D IRTE_DEST(cfg->dest_apicid); =20 - if (ir_data->irq_2_iommu.posted_msi) - intel_ir_reconfigure_irte_posted(irqd); - else if (force || ir_data->irq_2_iommu.mode =3D=3D IRQ_REMAPPING) - modify_irte(&ir_data->irq_2_iommu, irte); + __intel_ir_reconfigure_irte(irqd, force_host); } =20 /* @@ -1240,7 +1247,7 @@ static int intel_ir_set_vcpu_affinity(struct irq_data= *data, void *info) =20 /* stop posting interrupts, back to the default mode */ if (!vcpu_pi_info) { - modify_irte(&ir_data->irq_2_iommu, &ir_data->irte_entry); + __intel_ir_reconfigure_irte(data, true); } else { struct irte irte_pi; =20 --=20 2.43.0 From nobody Wed Dec 17 08:53:03 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DA8A24E018 for ; Wed, 19 Mar 2025 02:20:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742350843; cv=none; b=BAG1l2XE75iK2XlfbgnAYFaCU33KvEKb5VFJCo9WDfWHTEVn9SG2lVGGTROKMhRo5wNoVWwvcTZXyy5o6Ic94oZebto+NzWXLezTiBCgdr0wXRnv8c3wBaYvcb6lVyW6gU+loEhrLIAPIFlAvOCFnJsnfqxGMcp6n+Dx0JyO88Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742350843; c=relaxed/simple; bh=kAWLR5rUwyglBNFMiHrAUO27C72Ztw3iIuXLmxZHb0c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=s71wUtcedbx0x9v+eDUkK01A1pQrrOIab3liqvW77iGxIArjxsIxWQ4QGUO0GeWvXM3HXGMTCks6qniZx1j9/eNwJ5gNQlLD1Yorvj7j5Dw0ozFiD9ch1Oirt/936x8+tS6MaQ5EE6BZODLhF3W9nvRJ1HFyzl6MhRmG/i1ExPI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Uy+zU/Cy; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Uy+zU/Cy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1742350842; x=1773886842; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kAWLR5rUwyglBNFMiHrAUO27C72Ztw3iIuXLmxZHb0c=; b=Uy+zU/CyWLlDWGQ6UgltqT4fG+LkXt19gi9mH2OBE9MZyMFCa+XfoOc0 xp8DAiAn5m8NIPyZcVB25SZro2zGuQy97cMVNKWvT9bcRhHf40G+rxgpj mGV75uSVxwWi1l5CGG2Fz1Cou2ZXXXjs4rUVpYiYbsA0r2RxJ7j4uExUs yS6bYO1qH3rHW0yLBCeP8xsD/sJRAH+qlgm6Q6ScrlBZiJKsAg1P+m98b hcpvN3m4meIL5xxZcbWlq/pZs9QjG3JKqz4mqKh4zbrMm7knHL/UfXRyH jJWk8t/HKSoIS16+TvAUx8nilnFVz0qytfxLfyw4pMa/XYXK+Y61M0bZI w==; X-CSE-ConnectionGUID: fu8BnX0nQOGpVKjo/rDUXw== X-CSE-MsgGUID: dHmV6LBfShyykXML6iMnHQ== X-IronPort-AV: E=McAfee;i="6700,10204,11377"; a="42693232" X-IronPort-AV: E=Sophos;i="6.14,258,1736841600"; d="scan'208";a="42693232" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2025 19:20:42 -0700 X-CSE-ConnectionGUID: RSlaQ8zRRI2+bnnE4gZa5w== X-CSE-MsgGUID: KdimuEI0TLqdpJF5IMo6IQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,258,1736841600"; d="scan'208";a="123372402" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa008.jf.intel.com with ESMTP; 18 Mar 2025 19:20:40 -0700 From: Lu Baolu To: Joerg Roedel Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 2/3] iommu/vt-d: Don't clobber posted vCPU IRTE when host IRQ affinity changes Date: Wed, 19 Mar 2025 10:21:00 +0800 Message-ID: <20250319022101.1053133-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250319022101.1053133-1-baolu.lu@linux.intel.com> References: <20250319022101.1053133-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sean Christopherson Don't overwrite an IRTE that is posting IRQs to a vCPU with a posted MSI entry if the host IRQ affinity happens to change. If/when the IRTE is reverted back to "host mode", it will be reconfigured as a posted MSI or remapped entry as appropriate. Drop the "mode" field, which doesn't differentiate between posted MSIs and posted vCPUs, in favor of a dedicated posted_vcpu flag. Note! The two posted_{msi,vcpu} flags are intentionally not mutually exclusive; an IRTE can transition between posted MSI and posted vCPU. Fixes: ed1e48ea4370 ("iommu/vt-d: Enable posted mode for device MSIs") Cc: stable@vger.kernel.org Cc: Thomas Gleixner Cc: Jacob Pan Signed-off-by: Sean Christopherson Link: https://lore.kernel.org/r/20250315025135.2365846-3-seanjc@google.com Signed-off-by: Lu Baolu --- drivers/iommu/intel/irq_remapping.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/drivers/iommu/intel/irq_remapping.c b/drivers/iommu/intel/irq_= remapping.c index c495b533103f..ea3ca5203919 100644 --- a/drivers/iommu/intel/irq_remapping.c +++ b/drivers/iommu/intel/irq_remapping.c @@ -25,11 +25,6 @@ #include "../irq_remapping.h" #include "../iommu-pages.h" =20 -enum irq_mode { - IRQ_REMAPPING, - IRQ_POSTING, -}; - struct ioapic_scope { struct intel_iommu *iommu; unsigned int id; @@ -49,8 +44,8 @@ struct irq_2_iommu { u16 irte_index; u16 sub_handle; u8 irte_mask; - enum irq_mode mode; bool posted_msi; + bool posted_vcpu; }; =20 struct intel_ir_data { @@ -138,7 +133,6 @@ static int alloc_irte(struct intel_iommu *iommu, irq_iommu->irte_index =3D index; irq_iommu->sub_handle =3D 0; irq_iommu->irte_mask =3D mask; - irq_iommu->mode =3D IRQ_REMAPPING; } raw_spin_unlock_irqrestore(&irq_2_ir_lock, flags); =20 @@ -193,8 +187,6 @@ static int modify_irte(struct irq_2_iommu *irq_iommu, =20 rc =3D qi_flush_iec(iommu, index, 0); =20 - /* Update iommu mode according to the IRTE mode */ - irq_iommu->mode =3D irte->pst ? IRQ_POSTING : IRQ_REMAPPING; raw_spin_unlock_irqrestore(&irq_2_ir_lock, flags); =20 return rc; @@ -1173,9 +1165,18 @@ static void __intel_ir_reconfigure_irte(struct irq_d= ata *irqd, bool force_host) { struct intel_ir_data *ir_data =3D irqd->chip_data; =20 + /* + * Don't modify IRTEs for IRQs that are being posted to vCPUs if the + * host CPU affinity changes. + */ + if (ir_data->irq_2_iommu.posted_vcpu && !force_host) + return; + + ir_data->irq_2_iommu.posted_vcpu =3D false; + if (ir_data->irq_2_iommu.posted_msi) intel_ir_reconfigure_irte_posted(irqd); - else if (force_host || ir_data->irq_2_iommu.mode =3D=3D IRQ_REMAPPING) + else modify_irte(&ir_data->irq_2_iommu, &ir_data->irte_entry); } =20 @@ -1270,6 +1271,7 @@ static int intel_ir_set_vcpu_affinity(struct irq_data= *data, void *info) irte_pi.pda_h =3D (vcpu_pi_info->pi_desc_addr >> 32) & ~(-1UL << PDA_HIGH_BIT); =20 + ir_data->irq_2_iommu.posted_vcpu =3D true; modify_irte(&ir_data->irq_2_iommu, &irte_pi); } =20 @@ -1496,6 +1498,9 @@ static void intel_irq_remapping_deactivate(struct irq= _domain *domain, struct intel_ir_data *data =3D irq_data->chip_data; struct irte entry; =20 + WARN_ON_ONCE(data->irq_2_iommu.posted_vcpu); + data->irq_2_iommu.posted_vcpu =3D false; + memset(&entry, 0, sizeof(entry)); modify_irte(&data->irq_2_iommu, &entry); } --=20 2.43.0 From nobody Wed Dec 17 08:53:03 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A8CC24E4DD for ; Wed, 19 Mar 2025 02:20:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742350845; cv=none; b=Ju79dNQWCeltrArDzYGt9fypFW1eIVsdwqYLkvFaUPDG02fWSJ1GHjQQ78gApWpP/odulc105uGnuzA3H5l79BQTJOevKkmzAGOJmrknLWaDgB15UfFNwQzFslyUBeoIjShbia5VLumF/+mOmgHjInXsMNCeQ9hUFJTlfXH66Lc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742350845; c=relaxed/simple; bh=F1IGoDl2XTpIMbuR+jeJTSae0+Wtcwxi+ipULB/SmAs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DR8V3mVn8YlBUS5JdlmKezfUfcdsiez9ALMQeKXPKZ9bbigxls72hvW8PxyWCGJC0QuJMsEpNc1drjkGI/dFWUfaLMr1dPuBhhOmZQIRimSxukKDF/NPF55oOg0m/u0/7Oy2pcOENer+qQTAoPgA9QQFv2b0+dtgZYIOdr9AkLc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=oCrGCL4S; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="oCrGCL4S" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1742350843; x=1773886843; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=F1IGoDl2XTpIMbuR+jeJTSae0+Wtcwxi+ipULB/SmAs=; b=oCrGCL4ShI0A4MI970bY4ke7oWzWADFy0M+dux2k2WnmisKetJSCQYyg 20g00JfUOfVmuUvm8JAuRs5UnIX5EJqzXwiKdU7+D3KP3yUU7r3subPWW rfwA8/GsPTq1C3t6Sr7AZo/QoZvowhsr4QrJTqgteq4mUGmN1fHw4bEvg NmnMnS1szOX2GU52E2MHgcb92EuWhMZEPjR8drs686ITL4Czn7SQFHK66 S08N5IBHuYYQp8Jf9ABplvi0a782SO/JaVh7MgQwVGBE4bnF/i2j2vHiE TJM7b2HC4PZDASi9zvaR/ySKvq/nM3mkr8piIMqQZXVG5mSeyWcz/YAbQ A==; X-CSE-ConnectionGUID: 3zxJOZFDSFSdYPxepmnpeA== X-CSE-MsgGUID: vGKSu+2vQEya3kmSRkx9tw== X-IronPort-AV: E=McAfee;i="6700,10204,11377"; a="42693235" X-IronPort-AV: E=Sophos;i="6.14,258,1736841600"; d="scan'208";a="42693235" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2025 19:20:43 -0700 X-CSE-ConnectionGUID: J3tO3Sq7R6+VnB72dD10TQ== X-CSE-MsgGUID: uspph6RLSQq91ZzioORlbw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,258,1736841600"; d="scan'208";a="123372405" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa008.jf.intel.com with ESMTP; 18 Mar 2025 19:20:42 -0700 From: Lu Baolu To: Joerg Roedel Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 3/3] iommu/vt-d: Fix possible circular locking dependency Date: Wed, 19 Mar 2025 10:21:01 +0800 Message-ID: <20250319022101.1053133-4-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250319022101.1053133-1-baolu.lu@linux.intel.com> References: <20250319022101.1053133-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" We have recently seen report of lockdep circular lock dependency warnings on platforms like Skylake and Kabylake: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D WARNING: possible circular locking dependency detected 6.14.0-rc6-CI_DRM_16276-gca2c04fe76e8+ #1 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: ffffffff8360ee48 (iommu_probe_device_lock){+.+.}-{3:3}, at: iommu_probe_device+0x1d/0x70 but task is already holding lock: ffff888102c7efa8 (&device->physical_node_lock){+.+.}-{3:3}, at: intel_iommu_init+0xe75/0x11f0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #6 (&device->physical_node_lock){+.+.}-{3:3}: __mutex_lock+0xb4/0xe40 mutex_lock_nested+0x1b/0x30 intel_iommu_init+0xe75/0x11f0 pci_iommu_init+0x13/0x70 do_one_initcall+0x62/0x3f0 kernel_init_freeable+0x3da/0x6a0 kernel_init+0x1b/0x200 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1a/0x30 -> #5 (dmar_global_lock){++++}-{3:3}: down_read+0x43/0x1d0 enable_drhd_fault_handling+0x21/0x110 cpuhp_invoke_callback+0x4c6/0x870 cpuhp_issue_call+0xbf/0x1f0 __cpuhp_setup_state_cpuslocked+0x111/0x320 __cpuhp_setup_state+0xb0/0x220 irq_remap_enable_fault_handling+0x3f/0xa0 apic_intr_mode_init+0x5c/0x110 x86_late_time_init+0x24/0x40 start_kernel+0x895/0xbd0 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xbf/0x110 common_startup_64+0x13e/0x141 -> #4 (cpuhp_state_mutex){+.+.}-{3:3}: __mutex_lock+0xb4/0xe40 mutex_lock_nested+0x1b/0x30 __cpuhp_setup_state_cpuslocked+0x67/0x320 __cpuhp_setup_state+0xb0/0x220 page_alloc_init_cpuhp+0x2d/0x60 mm_core_init+0x18/0x2c0 start_kernel+0x576/0xbd0 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xbf/0x110 common_startup_64+0x13e/0x141 -> #3 (cpu_hotplug_lock){++++}-{0:0}: __cpuhp_state_add_instance+0x4f/0x220 iova_domain_init_rcaches+0x214/0x280 iommu_setup_dma_ops+0x1a4/0x710 iommu_device_register+0x17d/0x260 intel_iommu_init+0xda4/0x11f0 pci_iommu_init+0x13/0x70 do_one_initcall+0x62/0x3f0 kernel_init_freeable+0x3da/0x6a0 kernel_init+0x1b/0x200 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1a/0x30 -> #2 (&domain->iova_cookie->mutex){+.+.}-{3:3}: __mutex_lock+0xb4/0xe40 mutex_lock_nested+0x1b/0x30 iommu_setup_dma_ops+0x16b/0x710 iommu_device_register+0x17d/0x260 intel_iommu_init+0xda4/0x11f0 pci_iommu_init+0x13/0x70 do_one_initcall+0x62/0x3f0 kernel_init_freeable+0x3da/0x6a0 kernel_init+0x1b/0x200 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1a/0x30 -> #1 (&group->mutex){+.+.}-{3:3}: __mutex_lock+0xb4/0xe40 mutex_lock_nested+0x1b/0x30 __iommu_probe_device+0x24c/0x4e0 probe_iommu_group+0x2b/0x50 bus_for_each_dev+0x7d/0xe0 iommu_device_register+0xe1/0x260 intel_iommu_init+0xda4/0x11f0 pci_iommu_init+0x13/0x70 do_one_initcall+0x62/0x3f0 kernel_init_freeable+0x3da/0x6a0 kernel_init+0x1b/0x200 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1a/0x30 -> #0 (iommu_probe_device_lock){+.+.}-{3:3}: __lock_acquire+0x1637/0x2810 lock_acquire+0xc9/0x300 __mutex_lock+0xb4/0xe40 mutex_lock_nested+0x1b/0x30 iommu_probe_device+0x1d/0x70 intel_iommu_init+0xe90/0x11f0 pci_iommu_init+0x13/0x70 do_one_initcall+0x62/0x3f0 kernel_init_freeable+0x3da/0x6a0 kernel_init+0x1b/0x200 ret_from_fork+0x44/0x70 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Chain exists of: iommu_probe_device_lock --> dmar_global_lock --> &device->physical_node_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&device->physical_node_lock); lock(dmar_global_lock); lock(&device->physical_node_lock); lock(iommu_probe_device_lock); *** DEADLOCK *** This driver uses a global lock to protect the list of enumerated DMA remapping units. It is necessary due to the driver's support for dynamic addition and removal of remapping units at runtime. Two distinct code paths require iteration over this remapping unit list: - Device registration and probing: the driver iterates the list to register each remapping unit with the upper layer IOMMU framework and subsequently probe the devices managed by that unit. - Global configuration: Upper layer components may also iterate the list to apply configuration changes. The lock acquisition order between these two code paths was reversed. This caused lockdep warnings, indicating a risk of deadlock. Fix this warning by releasing the global lock before invoking upper layer interfaces for device registration. Fixes: b150654f74bf ("iommu/vt-d: Fix suspicious RCU usage") Closes: https://lore.kernel.org/linux-iommu/SJ1PR11MB612953431F94F18C954C4A= 9CB9D32@SJ1PR11MB6129.namprd11.prod.outlook.com/ Tested-by: Chaitanya Kumar Borah Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20250317035714.1041549-1-baolu.lu@linux.int= el.com --- drivers/iommu/intel/iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 85aa66ef4d61..ec2f385ae25b 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3049,6 +3049,7 @@ static int __init probe_acpi_namespace_devices(void) if (dev->bus !=3D &acpi_bus_type) continue; =20 + up_read(&dmar_global_lock); adev =3D to_acpi_device(dev); mutex_lock(&adev->physical_node_lock); list_for_each_entry(pn, @@ -3058,6 +3059,7 @@ static int __init probe_acpi_namespace_devices(void) break; } mutex_unlock(&adev->physical_node_lock); + down_read(&dmar_global_lock); =20 if (ret) return ret; --=20 2.43.0