Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp641751ybm; Tue, 21 May 2019 00:39:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqwtQ+nVdGxps//3xe4AELRG0eFtgzjrc8N7ZrZuognGJ95nBFoWI+AYSXdu9TJRjQhCrQYP X-Received: by 2002:a62:460a:: with SMTP id t10mr84208226pfa.3.1558424383223; Tue, 21 May 2019 00:39:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558424383; cv=none; d=google.com; s=arc-20160816; b=FdWXnAItKsgXrFRUorpZFFVOETJ3FExiJMIQTTUIM15xLisFZdg+MtdVu8O9OiQTXI rR3w4SK5x2xsgsnVusDBNhChRfRuWOb8Psrd3v1rHz7yt9NysnKQoQ/KdvkCMYNdf9jW vltSAW/42f2gwUhCmEKpW1kuo/MFEZVc8KYVXC8KSjwSCoIMwjx6uz/D12Uv42haFmxy 7J7I/1NgUN/I7gXskASgRH2DeEiemIWnr0uxixejhMOGSvxBQeotgtt0RLb55dY7iGrT /Pl60cc7Mljie9kXUCwPsYgcZd15sMe7Aj+iGW53D68sNmFLNjdd6BS4z0E6NWY1LHx0 RCbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=C4+XFGyvDsHOEcyoqkCtYgDTe4f5BeRoN5IDWErObNk=; b=bhR2j0zTh/K5X0srJveKDpKV1WfohyfXNlhAPfbo0Rk5yAQS/I5KD1PfeCTS8c/qN7 xToiHVTuwa91GYoLXMqyb9wurXed4REqUch29XVUIQpm7Ky2/R89x0TNv2omMV9D0OGX 4/T+4wYhJDG3+Q1KYKj9MWyyuIT4x/1/qPt3Otr34PSwpULcG6NKTINBD40tMI704S2t fYDGJlU8Yrm2is2fcLJCR4B/KH+FLMy6uNOZEib+wUnvIndGQty9rTsUTWHofqPpgkdA WFIk3m0ug6kJ/EFlpGlQNnG4TP+l/lNL1jpeUdMtfvjERsSQkCZ/KRC3/fQckgExomOt 8Eqw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d16si20662161pfr.229.2019.05.21.00.39.28; Tue, 21 May 2019 00:39:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726419AbfEUHhM (ORCPT + 99 others); Tue, 21 May 2019 03:37:12 -0400 Received: from mga18.intel.com ([134.134.136.126]:4506 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726006AbfEUHhM (ORCPT ); Tue, 21 May 2019 03:37:12 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 May 2019 00:37:11 -0700 X-ExtLoop1: 1 Received: from allen-box.sh.intel.com ([10.239.159.136]) by orsmga005.jf.intel.com with ESMTP; 21 May 2019 00:37:09 -0700 From: Lu Baolu To: joro@8bytes.org, dwmw2@infradead.org Cc: ashok.raj@intel.com, jacob.jun.pan@linux.intel.com, Kevin Tian , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Dave Jiang Subject: [PATCH 1/2] iommu/vt-d: Fix lock inversion between iommu->lock and device_domain_lock Date: Tue, 21 May 2019 15:30:15 +0800 Message-Id: <20190521073016.27525-1-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Jiang Lockdep debug reported lock inversion related with the iommu code caused by dmar_insert_one_dev_info() grabbing the iommu->lock and the device_domain_lock out of order versus the code path in iommu_flush_dev_iotlb(). Expanding the scope of the iommu->lock and reversing the order of lock acquisition fixes the issue. [ 76.238180] dsa_bus wq0.0: dsa wq wq0.0 disabled [ 76.248706] [ 76.250486] ======================================================== [ 76.257113] WARNING: possible irq lock inversion dependency detected [ 76.263736] 5.1.0-rc5+ #162 Not tainted [ 76.267854] -------------------------------------------------------- [ 76.274485] systemd-journal/521 just changed the state of lock: [ 76.280685] 0000000055b330f5 (device_domain_lock){..-.}, at: iommu_flush_dev_iotlb.part.63+0x29/0x90 [ 76.290099] but this lock took another, SOFTIRQ-unsafe lock in the past: [ 76.297093] (&(&iommu->lock)->rlock){+.+.} [ 76.297094] [ 76.297094] [ 76.297094] and interrupts could create inverse lock ordering between them. [ 76.297094] [ 76.314257] [ 76.314257] other info that might help us debug this: [ 76.321448] Possible interrupt unsafe locking scenario: [ 76.321448] [ 76.328907] CPU0 CPU1 [ 76.333777] ---- ---- [ 76.338642] lock(&(&iommu->lock)->rlock); [ 76.343165] local_irq_disable(); [ 76.349422] lock(device_domain_lock); [ 76.356116] lock(&(&iommu->lock)->rlock); [ 76.363154] [ 76.366134] lock(device_domain_lock); [ 76.370548] [ 76.370548] *** DEADLOCK *** Fixes: 745f2586e78e ("iommu/vt-d: Simplify function get_domain_for_dev()") Signed-off-by: Dave Jiang Reviewed-by: Lu Baolu --- drivers/iommu/intel-iommu.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index a209199f3af6..91f4912c09c6 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -2512,6 +2512,7 @@ static struct dmar_domain *dmar_insert_one_dev_info(struct intel_iommu *iommu, } } + spin_lock(&iommu->lock); spin_lock_irqsave(&device_domain_lock, flags); if (dev) found = find_domain(dev); @@ -2527,17 +2528,16 @@ static struct dmar_domain *dmar_insert_one_dev_info(struct intel_iommu *iommu, if (found) { spin_unlock_irqrestore(&device_domain_lock, flags); + spin_unlock(&iommu->lock); free_devinfo_mem(info); /* Caller must free the original domain */ return found; } - spin_lock(&iommu->lock); ret = domain_attach_iommu(domain, iommu); - spin_unlock(&iommu->lock); - if (ret) { spin_unlock_irqrestore(&device_domain_lock, flags); + spin_unlock(&iommu->lock); free_devinfo_mem(info); return NULL; } @@ -2547,6 +2547,7 @@ static struct dmar_domain *dmar_insert_one_dev_info(struct intel_iommu *iommu, if (dev) dev->archdata.iommu = info; spin_unlock_irqrestore(&device_domain_lock, flags); + spin_unlock(&iommu->lock); /* PASID table is mandatory for a PCI device in scalable mode. */ if (dev && dev_is_pci(dev) && sm_supported(iommu)) { -- 2.17.1