Message ID | 20231217114902.3836260-3-haifeng.zhao@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-2557-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:24d3:b0:fb:cd0c:d3e with SMTP id r19csp664002dyi; Sun, 17 Dec 2023 03:51:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IHtz3fu+IggEBRx1yrBTxdepvNB/hZRk/pD7bI/1Ti2zGVTtrHaKWGcvlRqYAapDHsHPJ8Q X-Received: by 2002:a17:90a:fb81:b0:28b:61cb:51ac with SMTP id cp1-20020a17090afb8100b0028b61cb51acmr369089pjb.78.1702813866452; Sun, 17 Dec 2023 03:51:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702813866; cv=none; d=google.com; s=arc-20160816; b=ZAQeMj9AgDvzW+tFiK4l6xt4CUO8g839g7RhiB4ZP9ltcgO2zwyGgRK3tXQ8iMFvI4 fKEtWuNvVRK/Hrl+I5nSEG9yIKsh1NDjwr4IyAkPv2BsWxcbtSDB4oETictjLfjWttYE rbSRwUCvWoa8PmcIuvuWtp+pDHP4PJ7JDmM7tuy4+tREvwrG/T97Ojrj+T4dbIFnVJ0L nz7NvHeAo+uM25Zfv4XCHCp/T9sN6pIl5BfFpyniBDT7Fv2c4Fp5y5zAmnWN3oZFbT4T 6c59MnCTHkCRr72aurTC5OwRjt/ZsZ54cHss/qXaojS7EKq1yxOsqLtN14ZZIUiJRF6f y8EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=FL1ZAhu/DZYVDOKUIld4CfL6Bmc7+dFddjaO5xHQR9s=; fh=cQTxynQ7rGExgmbyXq8tNmd/VmE1Fzgt9QW51hABj2c=; b=nW6iuBo5vFdPTshR2TPN0qYKbO69DuzMo7iv5WmtdHDaFlVvugLTUa2fawAUOT6c0A r/ht+SLfkw4zG9/FksrDstZ5Htku9O5SWb0R0+B6WXPA7gKrLBDBLfH5zltyHvSHN8Wx RBYKR7CKaA0ELWzonZ4CLsSoop55QNbK6QWzxaGxECUVSwiV9o9vnUUDISZltZIMDImg i/S+7hO3f+UEINwZ42O5FnkdYoAxtTqY93QmbqFHCfUODgmkS9JgEJWv3DlIn35TNyjT 9iC2pZmp+ORl7TI9plZUPP/RpFyLkfiJNf8drExPX2qgFmzfPtZWTaqnen/g9OZTsJ8w 4oDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="T/SJnO1+"; spf=pass (google.com: domain of linux-kernel+bounces-2557-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-2557-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id p1-20020a17090a868100b00286f189a050si1570591pjn.22.2023.12.17.03.51.05 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Dec 2023 03:51:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-2557-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="T/SJnO1+"; spf=pass (google.com: domain of linux-kernel+bounces-2557-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-2557-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 0A147B2174F for <ouuuleilei@gmail.com>; Sun, 17 Dec 2023 11:50:13 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 28B14321B6; Sun, 17 Dec 2023 11:49:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="T/SJnO1+" X-Original-To: linux-kernel@vger.kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 EC3193308A; Sun, 17 Dec 2023 11:49:16 +0000 (UTC) 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1702813757; x=1734349757; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=cWXn+TxaT3YR7lZfs1eo26jXNNMGOmRyXKjKAQbJKyc=; b=T/SJnO1+HGUDvfu9AN4Mv/jJJD5aN26lgdmo4hAEAsaGx3dhNCa4S+qF 0pGjZOcXesELIErHnyvioKVgNcsBZiwjzuYAu02/KGov2evmry0lUMwM+ rGF7Iys4OacY1d/EY2YRw+RK9ttkIrwTx/nseCKjSw25CwGLHdwSTifXh 6IdzaZ9Pixl00yaw/FHQCOSJ6Iuv4gxbsJjmSJESKxfMtCnAfl2E+uqLg /dOn0gCHlND4BbgYNxNaztwmNleAoKsDRUR96ndTUTbOHfTd8KmubTOdg UxwNDEkf4yoh2gXYHirfW/a/Xtj0UkIcMBLphaCwqh2/qfnTqwBCsPHvY Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10926"; a="2599477" X-IronPort-AV: E=Sophos;i="6.04,283,1695711600"; d="scan'208";a="2599477" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Dec 2023 03:49:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10926"; a="751454185" X-IronPort-AV: E=Sophos;i="6.04,283,1695711600"; d="scan'208";a="751454185" Received: from ply01-vm-store.bj.intel.com ([10.238.153.201]) by orsmga006.jf.intel.com with ESMTP; 17 Dec 2023 03:49:11 -0800 From: Ethan Zhao <haifeng.zhao@linux.intel.com> To: bhelgaas@google.com, baolu.lu@linux.intel.com, dwmw2@infradead.org, will@kernel.org, robin.murphy@arm.com, lukas@wunner.de Cc: linux-pci@vger.kernel.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v3 2/2] iommu/vt-d: don's issue devTLB flush request when device is disconnected Date: Sun, 17 Dec 2023 06:49:02 -0500 Message-Id: <20231217114902.3836260-3-haifeng.zhao@linux.intel.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20231217114902.3836260-1-haifeng.zhao@linux.intel.com> References: <20231217114902.3836260-1-haifeng.zhao@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785529752435154846 X-GMAIL-MSGID: 1785529752435154846 |
Series |
fix vt-d hard lockup when hotplug ATS capable device
|
|
Commit Message
Ethan Zhao
Dec. 17, 2023, 11:49 a.m. UTC
For those endpoint devices connect to system via hotplug capable ports, users could request a warm reset to the device by flapping device's link through setting the slot's link control register, as pciehpt_ist() DLLSC interrupt sequence response, pciehp will unload the device driver and then power it off. thus cause an IOMMU devTLB flush request for device to be sent and a long time completion/timeout waiting in interrupt context. That would cause following continuous hard lockup warning and system hang [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144 [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S OE kernel version xxxx [ 4223.822623] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490 [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005 [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340 [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000 [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200 [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004 [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000) knlGS:0000000000000000 [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0 [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 4223.822628] PKRU: 55555554 [ 4223.822628] Call Trace: [ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0 [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250 [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50 [ 4223.822629] intel_iommu_release_device+0x1f/0x30 [ 4223.822629] iommu_release_device+0x33/0x60 [ 4223.822629] iommu_bus_notifier+0x7f/0x90 [ 4223.822630] blocking_notifier_call_chain+0x60/0x90 [ 4223.822630] device_del+0x2e5/0x420 [ 4223.822630] pci_remove_bus_device+0x70/0x110 [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130 [ 4223.822631] pciehp_disable_slot+0x6b/0x100 [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320 [ 4223.822631] pciehp_ist+0x176/0x180 [ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110 [ 4223.822632] irq_thread_fn+0x19/0x50 [ 4223.822632] irq_thread+0x104/0x190 [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90 [ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0 [ 4223.822633] kthread+0x114/0x130 [ 4223.822633] ? __kthread_cancel_work+0x40/0x40 [ 4223.822633] ret_from_fork+0x1f/0x30 [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S OE kernel version xxxx [ 4223.822634] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822634] Call Trace: [ 4223.822634] <NMI> [ 4223.822635] dump_stack+0x6d/0x88 [ 4223.822635] panic+0x101/0x2d0 [ 4223.822635] ? ret_from_fork+0x11/0x30 [ 4223.822635] nmi_panic.cold.14+0xc/0xc [ 4223.822636] watchdog_overflow_callback.cold.8+0x6d/0x81 [ 4223.822636] __perf_event_overflow+0x4f/0xf0 [ 4223.822636] handle_pmi_common+0x1ef/0x290 [ 4223.822636] ? __set_pte_vaddr+0x28/0x40 [ 4223.822637] ? flush_tlb_one_kernel+0xa/0x20 [ 4223.822637] ? __native_set_fixmap+0x24/0x30 [ 4223.822637] ? ghes_copy_tofrom_phys+0x70/0x100 [ 4223.822637] ? __ghes_peek_estatus.isra.16+0x49/0xa0 [ 4223.822637] intel_pmu_handle_irq+0xba/0x2b0 [ 4223.822638] perf_event_nmi_handler+0x24/0x40 [ 4223.822638] nmi_handle+0x4d/0xf0 [ 4223.822638] default_do_nmi+0x49/0x100 [ 4223.822638] exc_nmi+0x134/0x180 [ 4223.822639] end_repeat_nmi+0x16/0x67 [ 4223.822639] RIP: 0010:qi_submit_sync+0x2c0/0x490 [ 4223.822639] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 10 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 [ 4223.822640] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 [ 4223.822640] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005 [ 4223.822640] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340 [ 4223.822641] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000 [ 4223.822641] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200 [ 4223.822641] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004 [ 4223.822641] ? qi_submit_sync+0x2c0/0x490 [ 4223.822642] ? qi_submit_sync+0x2c0/0x490 [ 4223.822642] </NMI> [ 4223.822642] qi_flush_dev_iotlb+0xb1/0xd0 [ 4223.822642] __dmar_remove_one_dev_info+0x224/0x250 [ 4223.822643] dmar_remove_one_dev_info+0x3e/0x50 [ 4223.822643] intel_iommu_release_device+0x1f/0x30 [ 4223.822643] iommu_release_device+0x33/0x60 [ 4223.822643] iommu_bus_notifier+0x7f/0x90 [ 4223.822644] blocking_notifier_call_chain+0x60/0x90 [ 4223.822644] device_del+0x2e5/0x420 [ 4223.822644] pci_remove_bus_device+0x70/0x110 [ 4223.822644] pciehp_unconfigure_device+0x7c/0x130 [ 4223.822644] pciehp_disable_slot+0x6b/0x100 [ 4223.822645] pciehp_handle_presence_or_link_change+0xd8/0x320 [ 4223.822645] pciehp_ist+0x176/0x180 [ 4223.822645] ? irq_finalize_oneshot.part.50+0x110/0x110 [ 4223.822645] irq_thread_fn+0x19/0x50 [ 4223.822646] irq_thread+0x104/0x190 [ 4223.822646] ? irq_forced_thread_fn+0x90/0x90 [ 4223.822646] ? irq_thread_check_affinity+0xe0/0xe0 [ 4223.822646] kthread+0x114/0x130 [ 4223.822647] ? __kthread_cancel_work+0x40/0x40 [ 4223.822647] ret_from_fork+0x1f/0x30 [ 4223.822647] Kernel Offset: 0x6400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Fix it by checking the device's error_state in devtlb_invalidation_with_pasid() to avoid sending meaningless devTLB flush request to link down device that is set to pci_channel_io_perm_failure and then powered off in pciehp_ist() pciehp_handle_presence_or_link_change() pciehp_disable_slot() remove_board() pciehp_unconfigure_device() For SAFE_REMOVAL unplug, link is alive when iommu releases device and issues devTLB invalidate request, wouldn't trigger such issue. This patch works for all kinds of SURPPRISE_REMOVAL unplug operation. Tested-by: Haorong Ye <yehaorong@bytedance.com> Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> --- drivers/iommu/intel/pasid.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
Comments
On 2023/12/17 19:49, Ethan Zhao wrote: > For those endpoint devices connect to system via hotplug capable ports, > users could request a warm reset to the device by flapping device's link > through setting the slot's link control register, as pciehpt_ist() DLLSC > interrupt sequence response, pciehp will unload the device driver and > then power it off. thus cause an IOMMU devTLB flush request for device to > be sent and a long time completion/timeout waiting in interrupt context. > > That would cause following continuous hard lockup warning and system hang > > [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down > [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present > [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144 > [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S > OE kernel version xxxx > [ 4223.822623] Hardware name: vendorname xxxx 666-106, > BIOS 01.01.02.03.01 05/15/2023 > [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490 > [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b > 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1 > 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 > [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 > [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005 > [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340 > [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000 > [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200 > [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004 > [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000) > knlGS:0000000000000000 > [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0 > [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 > [ 4223.822628] PKRU: 55555554 > [ 4223.822628] Call Trace: > [ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0 > [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250 > [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50 > [ 4223.822629] intel_iommu_release_device+0x1f/0x30 > [ 4223.822629] iommu_release_device+0x33/0x60 > [ 4223.822629] iommu_bus_notifier+0x7f/0x90 > [ 4223.822630] blocking_notifier_call_chain+0x60/0x90 > [ 4223.822630] device_del+0x2e5/0x420 > [ 4223.822630] pci_remove_bus_device+0x70/0x110 > [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130 > [ 4223.822631] pciehp_disable_slot+0x6b/0x100 > [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320 > [ 4223.822631] pciehp_ist+0x176/0x180 > [ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110 > [ 4223.822632] irq_thread_fn+0x19/0x50 > [ 4223.822632] irq_thread+0x104/0x190 > [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90 > [ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0 > [ 4223.822633] kthread+0x114/0x130 > [ 4223.822633] ? __kthread_cancel_work+0x40/0x40 > [ 4223.822633] ret_from_fork+0x1f/0x30 > [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP > [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S > OE kernel version xxxx > [ 4223.822634] Hardware name: vendorname xxxx 666-106, > BIOS 01.01.02.03.01 05/15/2023 > [ 4223.822634] Call Trace: > [ 4223.822634] <NMI> > [ 4223.822635] dump_stack+0x6d/0x88 > [ 4223.822635] panic+0x101/0x2d0 > [ 4223.822635] ? ret_from_fork+0x11/0x30 > [ 4223.822635] nmi_panic.cold.14+0xc/0xc > [ 4223.822636] watchdog_overflow_callback.cold.8+0x6d/0x81 > [ 4223.822636] __perf_event_overflow+0x4f/0xf0 > [ 4223.822636] handle_pmi_common+0x1ef/0x290 > [ 4223.822636] ? __set_pte_vaddr+0x28/0x40 > [ 4223.822637] ? flush_tlb_one_kernel+0xa/0x20 > [ 4223.822637] ? __native_set_fixmap+0x24/0x30 > [ 4223.822637] ? ghes_copy_tofrom_phys+0x70/0x100 > [ 4223.822637] ? __ghes_peek_estatus.isra.16+0x49/0xa0 > [ 4223.822637] intel_pmu_handle_irq+0xba/0x2b0 > [ 4223.822638] perf_event_nmi_handler+0x24/0x40 > [ 4223.822638] nmi_handle+0x4d/0xf0 > [ 4223.822638] default_do_nmi+0x49/0x100 > [ 4223.822638] exc_nmi+0x134/0x180 > [ 4223.822639] end_repeat_nmi+0x16/0x67 > [ 4223.822639] RIP: 0010:qi_submit_sync+0x2c0/0x490 > [ 4223.822639] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b > 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 10 > 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 > [ 4223.822640] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 > [ 4223.822640] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005 > [ 4223.822640] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340 > [ 4223.822641] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000 > [ 4223.822641] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200 > [ 4223.822641] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004 > [ 4223.822641] ? qi_submit_sync+0x2c0/0x490 > [ 4223.822642] ? qi_submit_sync+0x2c0/0x490 > [ 4223.822642] </NMI> > [ 4223.822642] qi_flush_dev_iotlb+0xb1/0xd0 > [ 4223.822642] __dmar_remove_one_dev_info+0x224/0x250 > [ 4223.822643] dmar_remove_one_dev_info+0x3e/0x50 > [ 4223.822643] intel_iommu_release_device+0x1f/0x30 > [ 4223.822643] iommu_release_device+0x33/0x60 > [ 4223.822643] iommu_bus_notifier+0x7f/0x90 > [ 4223.822644] blocking_notifier_call_chain+0x60/0x90 > [ 4223.822644] device_del+0x2e5/0x420 > [ 4223.822644] pci_remove_bus_device+0x70/0x110 > [ 4223.822644] pciehp_unconfigure_device+0x7c/0x130 > [ 4223.822644] pciehp_disable_slot+0x6b/0x100 > [ 4223.822645] pciehp_handle_presence_or_link_change+0xd8/0x320 > [ 4223.822645] pciehp_ist+0x176/0x180 > [ 4223.822645] ? irq_finalize_oneshot.part.50+0x110/0x110 > [ 4223.822645] irq_thread_fn+0x19/0x50 > [ 4223.822646] irq_thread+0x104/0x190 > [ 4223.822646] ? irq_forced_thread_fn+0x90/0x90 > [ 4223.822646] ? irq_thread_check_affinity+0xe0/0xe0 > [ 4223.822646] kthread+0x114/0x130 > [ 4223.822647] ? __kthread_cancel_work+0x40/0x40 > [ 4223.822647] ret_from_fork+0x1f/0x30 > [ 4223.822647] Kernel Offset: 0x6400000 from 0xffffffff81000000 (relocation > range: 0xffffffff80000000-0xffffffffbfffffff) > > Fix it by checking the device's error_state in > devtlb_invalidation_with_pasid() to avoid sending meaningless devTLB flush > request to link down device that is set to pci_channel_io_perm_failure and > then powered off in > > pciehp_ist() > pciehp_handle_presence_or_link_change() > pciehp_disable_slot() > remove_board() > pciehp_unconfigure_device() > > For SAFE_REMOVAL unplug, link is alive when iommu releases device and > issues devTLB invalidate request, wouldn't trigger such issue. > > This patch works for all kinds of SURPPRISE_REMOVAL unplug operation. > > Tested-by: Haorong Ye <yehaorong@bytedance.com> > Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> > --- > drivers/iommu/intel/pasid.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c > index 74e8e4c17e81..182eb5df244d 100644 > --- a/drivers/iommu/intel/pasid.c > +++ b/drivers/iommu/intel/pasid.c > @@ -476,6 +476,23 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iommu, > { > struct device_domain_info *info; > u16 sid, qdep, pfsid; > + struct pci_dev *pdev; > + > + pdev = to_pci_dev(dev); > + if (!pdev) > + return; > + > + /* > + * If endpoint device's link was brough down by user's pci configuration > + * access to it's hotplug capable slot link control register, as sequence > + * response for DLLSC, pciehp_ist() will set the device error_state to > + * pci_channel_io_perm_failure. Checking device's state here to avoid > + * issuing meaningless devTLB flush request to it, that might cause lockup > + * warning or deadlock because too long time waiting in interrupt context. > + */ > + > + if (pci_dev_is_disconnected(pdev)) > + return; > > info = dev_iommu_priv_get(dev); > if (!info || !info->ats_enabled) It's likely better to check the device status after verifying ats_enabled. How about below change? diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c index 74e8e4c17e81..fa19c6cdfd8b 100644 --- a/drivers/iommu/intel/pasid.c +++ b/drivers/iommu/intel/pasid.c @@ -481,6 +481,9 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iommu, if (!info || !info->ats_enabled) return; + if (pci_dev_is_disconnected(to_pci_dev(dev))) + return + sid = info->bus << 8 | info->devfn; qdep = info->ats_qdep; pfsid = info->pfsid; Best regards, baolu
On 12/19/2023 2:09 PM, Baolu Lu wrote: > On 2023/12/17 19:49, Ethan Zhao wrote: >> For those endpoint devices connect to system via hotplug capable ports, >> users could request a warm reset to the device by flapping device's link >> through setting the slot's link control register, as pciehpt_ist() DLLSC >> interrupt sequence response, pciehp will unload the device driver and >> then power it off. thus cause an IOMMU devTLB flush request for >> device to >> be sent and a long time completion/timeout waiting in interrupt context. >> >> That would cause following continuous hard lockup warning and system >> hang >> >> [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down >> [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not >> present >> [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144 >> [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded >> Tainted: G S >> OE kernel version xxxx >> [ 4223.822623] Hardware name: vendorname xxxx 666-106, >> BIOS 01.01.02.03.01 05/15/2023 >> [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490 >> [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f >> 95 c1 48 8b >> 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 >> <40> f6 c6 1 >> 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 >> [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 >> [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: >> 0000000000000005 >> [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: >> ffff9f38401a8340 >> [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: >> 0000000000000000 >> [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: >> ffff9f384005e200 >> [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: >> 0000000000000004 >> [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000) >> knlGS:0000000000000000 >> [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: >> 0000000000770ee0 >> [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: >> 0000000000000000 >> [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: >> 0000000000000400 >> [ 4223.822628] PKRU: 55555554 >> [ 4223.822628] Call Trace: >> [ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0 >> [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250 >> [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50 >> [ 4223.822629] intel_iommu_release_device+0x1f/0x30 >> [ 4223.822629] iommu_release_device+0x33/0x60 >> [ 4223.822629] iommu_bus_notifier+0x7f/0x90 >> [ 4223.822630] blocking_notifier_call_chain+0x60/0x90 >> [ 4223.822630] device_del+0x2e5/0x420 >> [ 4223.822630] pci_remove_bus_device+0x70/0x110 >> [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130 >> [ 4223.822631] pciehp_disable_slot+0x6b/0x100 >> [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320 >> [ 4223.822631] pciehp_ist+0x176/0x180 >> [ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110 >> [ 4223.822632] irq_thread_fn+0x19/0x50 >> [ 4223.822632] irq_thread+0x104/0x190 >> [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90 >> [ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0 >> [ 4223.822633] kthread+0x114/0x130 >> [ 4223.822633] ? __kthread_cancel_work+0x40/0x40 >> [ 4223.822633] ret_from_fork+0x1f/0x30 >> [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP >> [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded >> Tainted: G S >> OE kernel version xxxx >> [ 4223.822634] Hardware name: vendorname xxxx 666-106, >> BIOS 01.01.02.03.01 05/15/2023 >> [ 4223.822634] Call Trace: >> [ 4223.822634] <NMI> >> [ 4223.822635] dump_stack+0x6d/0x88 >> [ 4223.822635] panic+0x101/0x2d0 >> [ 4223.822635] ? ret_from_fork+0x11/0x30 >> [ 4223.822635] nmi_panic.cold.14+0xc/0xc >> [ 4223.822636] watchdog_overflow_callback.cold.8+0x6d/0x81 >> [ 4223.822636] __perf_event_overflow+0x4f/0xf0 >> [ 4223.822636] handle_pmi_common+0x1ef/0x290 >> [ 4223.822636] ? __set_pte_vaddr+0x28/0x40 >> [ 4223.822637] ? flush_tlb_one_kernel+0xa/0x20 >> [ 4223.822637] ? __native_set_fixmap+0x24/0x30 >> [ 4223.822637] ? ghes_copy_tofrom_phys+0x70/0x100 >> [ 4223.822637] ? __ghes_peek_estatus.isra.16+0x49/0xa0 >> [ 4223.822637] intel_pmu_handle_irq+0xba/0x2b0 >> [ 4223.822638] perf_event_nmi_handler+0x24/0x40 >> [ 4223.822638] nmi_handle+0x4d/0xf0 >> [ 4223.822638] default_do_nmi+0x49/0x100 >> [ 4223.822638] exc_nmi+0x134/0x180 >> [ 4223.822639] end_repeat_nmi+0x16/0x67 >> [ 4223.822639] RIP: 0010:qi_submit_sync+0x2c0/0x490 >> [ 4223.822639] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f >> 95 c1 48 8b >> 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 >> <40> f6 c6 10 >> 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 >> [ 4223.822640] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 >> [ 4223.822640] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: >> 0000000000000005 >> [ 4223.822640] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: >> ffff9f38401a8340 >> [ 4223.822641] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: >> 0000000000000000 >> [ 4223.822641] R10: 0000000000000010 R11: 0000000000000018 R12: >> ffff9f384005e200 >> [ 4223.822641] R13: 0000000000000004 R14: 0000000000000046 R15: >> 0000000000000004 >> [ 4223.822641] ? qi_submit_sync+0x2c0/0x490 >> [ 4223.822642] ? qi_submit_sync+0x2c0/0x490 >> [ 4223.822642] </NMI> >> [ 4223.822642] qi_flush_dev_iotlb+0xb1/0xd0 >> [ 4223.822642] __dmar_remove_one_dev_info+0x224/0x250 >> [ 4223.822643] dmar_remove_one_dev_info+0x3e/0x50 >> [ 4223.822643] intel_iommu_release_device+0x1f/0x30 >> [ 4223.822643] iommu_release_device+0x33/0x60 >> [ 4223.822643] iommu_bus_notifier+0x7f/0x90 >> [ 4223.822644] blocking_notifier_call_chain+0x60/0x90 >> [ 4223.822644] device_del+0x2e5/0x420 >> [ 4223.822644] pci_remove_bus_device+0x70/0x110 >> [ 4223.822644] pciehp_unconfigure_device+0x7c/0x130 >> [ 4223.822644] pciehp_disable_slot+0x6b/0x100 >> [ 4223.822645] pciehp_handle_presence_or_link_change+0xd8/0x320 >> [ 4223.822645] pciehp_ist+0x176/0x180 >> [ 4223.822645] ? irq_finalize_oneshot.part.50+0x110/0x110 >> [ 4223.822645] irq_thread_fn+0x19/0x50 >> [ 4223.822646] irq_thread+0x104/0x190 >> [ 4223.822646] ? irq_forced_thread_fn+0x90/0x90 >> [ 4223.822646] ? irq_thread_check_affinity+0xe0/0xe0 >> [ 4223.822646] kthread+0x114/0x130 >> [ 4223.822647] ? __kthread_cancel_work+0x40/0x40 >> [ 4223.822647] ret_from_fork+0x1f/0x30 >> [ 4223.822647] Kernel Offset: 0x6400000 from 0xffffffff81000000 >> (relocation >> range: 0xffffffff80000000-0xffffffffbfffffff) >> >> Fix it by checking the device's error_state in >> devtlb_invalidation_with_pasid() to avoid sending meaningless devTLB >> flush >> request to link down device that is set to >> pci_channel_io_perm_failure and >> then powered off in >> >> pciehp_ist() >> pciehp_handle_presence_or_link_change() >> pciehp_disable_slot() >> remove_board() >> pciehp_unconfigure_device() >> >> For SAFE_REMOVAL unplug, link is alive when iommu releases device and >> issues devTLB invalidate request, wouldn't trigger such issue. >> >> This patch works for all kinds of SURPPRISE_REMOVAL unplug operation. >> >> Tested-by: Haorong Ye <yehaorong@bytedance.com> >> Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> >> --- >> drivers/iommu/intel/pasid.c | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> >> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c >> index 74e8e4c17e81..182eb5df244d 100644 >> --- a/drivers/iommu/intel/pasid.c >> +++ b/drivers/iommu/intel/pasid.c >> @@ -476,6 +476,23 @@ devtlb_invalidation_with_pasid(struct >> intel_iommu *iommu, >> { >> struct device_domain_info *info; >> u16 sid, qdep, pfsid; >> + struct pci_dev *pdev; >> + >> + pdev = to_pci_dev(dev); >> + if (!pdev) >> + return; >> + >> + /* >> + * If endpoint device's link was brough down by user's pci >> configuration >> + * access to it's hotplug capable slot link control register, as >> sequence >> + * response for DLLSC, pciehp_ist() will set the device >> error_state to >> + * pci_channel_io_perm_failure. Checking device's state here to >> avoid >> + * issuing meaningless devTLB flush request to it, that might >> cause lockup >> + * warning or deadlock because too long time waiting in >> interrupt context. >> + */ >> + >> + if (pci_dev_is_disconnected(pdev)) >> + return; >> info = dev_iommu_priv_get(dev); >> if (!info || !info->ats_enabled) > > It's likely better to check the device status after verifying > ats_enabled. How about below change? > > diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c > index 74e8e4c17e81..fa19c6cdfd8b 100644 > --- a/drivers/iommu/intel/pasid.c > +++ b/drivers/iommu/intel/pasid.c > @@ -481,6 +481,9 @@ devtlb_invalidation_with_pasid(struct intel_iommu > *iommu, > if (!info || !info->ats_enabled) > return; > > + if (pci_dev_is_disconnected(to_pci_dev(dev))) > + return > + I did this in the first version, but I thought seconds, changed it. Anyway, not performance critical path, I am okay with them. Thanks, Ethan > sid = info->bus << 8 | info->devfn; > qdep = info->ats_qdep; > pfsid = info->pfsid; > > Best regards, > baolu
On 12/19/2023 2:09 PM, Baolu Lu wrote: > On 2023/12/17 19:49, Ethan Zhao wrote: >> For those endpoint devices connect to system via hotplug capable ports, >> users could request a warm reset to the device by flapping device's link >> through setting the slot's link control register, as pciehpt_ist() DLLSC >> interrupt sequence response, pciehp will unload the device driver and >> then power it off. thus cause an IOMMU devTLB flush request for >> device to >> be sent and a long time completion/timeout waiting in interrupt context. >> >> That would cause following continuous hard lockup warning and system >> hang >> >> [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down >> [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not >> present >> [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144 >> [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded >> Tainted: G S >> OE kernel version xxxx >> [ 4223.822623] Hardware name: vendorname xxxx 666-106, >> BIOS 01.01.02.03.01 05/15/2023 >> [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490 >> [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f >> 95 c1 48 8b >> 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 >> <40> f6 c6 1 >> 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 >> [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 >> [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: >> 0000000000000005 >> [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: >> ffff9f38401a8340 >> [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: >> 0000000000000000 >> [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: >> ffff9f384005e200 >> [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: >> 0000000000000004 >> [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000) >> knlGS:0000000000000000 >> [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: >> 0000000000770ee0 >> [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: >> 0000000000000000 >> [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: >> 0000000000000400 >> [ 4223.822628] PKRU: 55555554 >> [ 4223.822628] Call Trace: >> [ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0 >> [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250 >> [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50 >> [ 4223.822629] intel_iommu_release_device+0x1f/0x30 >> [ 4223.822629] iommu_release_device+0x33/0x60 >> [ 4223.822629] iommu_bus_notifier+0x7f/0x90 >> [ 4223.822630] blocking_notifier_call_chain+0x60/0x90 >> [ 4223.822630] device_del+0x2e5/0x420 >> [ 4223.822630] pci_remove_bus_device+0x70/0x110 >> [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130 >> [ 4223.822631] pciehp_disable_slot+0x6b/0x100 >> [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320 >> [ 4223.822631] pciehp_ist+0x176/0x180 >> [ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110 >> [ 4223.822632] irq_thread_fn+0x19/0x50 >> [ 4223.822632] irq_thread+0x104/0x190 >> [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90 >> [ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0 >> [ 4223.822633] kthread+0x114/0x130 >> [ 4223.822633] ? __kthread_cancel_work+0x40/0x40 >> [ 4223.822633] ret_from_fork+0x1f/0x30 >> [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP >> [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded >> Tainted: G S >> OE kernel version xxxx >> [ 4223.822634] Hardware name: vendorname xxxx 666-106, >> BIOS 01.01.02.03.01 05/15/2023 >> [ 4223.822634] Call Trace: >> [ 4223.822634] <NMI> >> [ 4223.822635] dump_stack+0x6d/0x88 >> [ 4223.822635] panic+0x101/0x2d0 >> [ 4223.822635] ? ret_from_fork+0x11/0x30 >> [ 4223.822635] nmi_panic.cold.14+0xc/0xc >> [ 4223.822636] watchdog_overflow_callback.cold.8+0x6d/0x81 >> [ 4223.822636] __perf_event_overflow+0x4f/0xf0 >> [ 4223.822636] handle_pmi_common+0x1ef/0x290 >> [ 4223.822636] ? __set_pte_vaddr+0x28/0x40 >> [ 4223.822637] ? flush_tlb_one_kernel+0xa/0x20 >> [ 4223.822637] ? __native_set_fixmap+0x24/0x30 >> [ 4223.822637] ? ghes_copy_tofrom_phys+0x70/0x100 >> [ 4223.822637] ? __ghes_peek_estatus.isra.16+0x49/0xa0 >> [ 4223.822637] intel_pmu_handle_irq+0xba/0x2b0 >> [ 4223.822638] perf_event_nmi_handler+0x24/0x40 >> [ 4223.822638] nmi_handle+0x4d/0xf0 >> [ 4223.822638] default_do_nmi+0x49/0x100 >> [ 4223.822638] exc_nmi+0x134/0x180 >> [ 4223.822639] end_repeat_nmi+0x16/0x67 >> [ 4223.822639] RIP: 0010:qi_submit_sync+0x2c0/0x490 >> [ 4223.822639] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f >> 95 c1 48 8b >> 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 >> <40> f6 c6 10 >> 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 >> [ 4223.822640] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 >> [ 4223.822640] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: >> 0000000000000005 >> [ 4223.822640] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: >> ffff9f38401a8340 >> [ 4223.822641] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: >> 0000000000000000 >> [ 4223.822641] R10: 0000000000000010 R11: 0000000000000018 R12: >> ffff9f384005e200 >> [ 4223.822641] R13: 0000000000000004 R14: 0000000000000046 R15: >> 0000000000000004 >> [ 4223.822641] ? qi_submit_sync+0x2c0/0x490 >> [ 4223.822642] ? qi_submit_sync+0x2c0/0x490 >> [ 4223.822642] </NMI> >> [ 4223.822642] qi_flush_dev_iotlb+0xb1/0xd0 >> [ 4223.822642] __dmar_remove_one_dev_info+0x224/0x250 >> [ 4223.822643] dmar_remove_one_dev_info+0x3e/0x50 >> [ 4223.822643] intel_iommu_release_device+0x1f/0x30 >> [ 4223.822643] iommu_release_device+0x33/0x60 >> [ 4223.822643] iommu_bus_notifier+0x7f/0x90 >> [ 4223.822644] blocking_notifier_call_chain+0x60/0x90 >> [ 4223.822644] device_del+0x2e5/0x420 >> [ 4223.822644] pci_remove_bus_device+0x70/0x110 >> [ 4223.822644] pciehp_unconfigure_device+0x7c/0x130 >> [ 4223.822644] pciehp_disable_slot+0x6b/0x100 >> [ 4223.822645] pciehp_handle_presence_or_link_change+0xd8/0x320 >> [ 4223.822645] pciehp_ist+0x176/0x180 >> [ 4223.822645] ? irq_finalize_oneshot.part.50+0x110/0x110 >> [ 4223.822645] irq_thread_fn+0x19/0x50 >> [ 4223.822646] irq_thread+0x104/0x190 >> [ 4223.822646] ? irq_forced_thread_fn+0x90/0x90 >> [ 4223.822646] ? irq_thread_check_affinity+0xe0/0xe0 >> [ 4223.822646] kthread+0x114/0x130 >> [ 4223.822647] ? __kthread_cancel_work+0x40/0x40 >> [ 4223.822647] ret_from_fork+0x1f/0x30 >> [ 4223.822647] Kernel Offset: 0x6400000 from 0xffffffff81000000 >> (relocation >> range: 0xffffffff80000000-0xffffffffbfffffff) >> >> Fix it by checking the device's error_state in >> devtlb_invalidation_with_pasid() to avoid sending meaningless devTLB >> flush >> request to link down device that is set to >> pci_channel_io_perm_failure and >> then powered off in >> >> pciehp_ist() >> pciehp_handle_presence_or_link_change() >> pciehp_disable_slot() >> remove_board() >> pciehp_unconfigure_device() >> >> For SAFE_REMOVAL unplug, link is alive when iommu releases device and >> issues devTLB invalidate request, wouldn't trigger such issue. >> >> This patch works for all kinds of SURPPRISE_REMOVAL unplug operation. >> >> Tested-by: Haorong Ye <yehaorong@bytedance.com> >> Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> >> --- >> drivers/iommu/intel/pasid.c | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> >> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c >> index 74e8e4c17e81..182eb5df244d 100644 >> --- a/drivers/iommu/intel/pasid.c >> +++ b/drivers/iommu/intel/pasid.c >> @@ -476,6 +476,23 @@ devtlb_invalidation_with_pasid(struct >> intel_iommu *iommu, >> { >> struct device_domain_info *info; >> u16 sid, qdep, pfsid; >> + struct pci_dev *pdev; >> + >> + pdev = to_pci_dev(dev); >> + if (!pdev) >> + return; >> + >> + /* >> + * If endpoint device's link was brough down by user's pci >> configuration >> + * access to it's hotplug capable slot link control register, as >> sequence >> + * response for DLLSC, pciehp_ist() will set the device >> error_state to >> + * pci_channel_io_perm_failure. Checking device's state here to >> avoid >> + * issuing meaningless devTLB flush request to it, that might >> cause lockup >> + * warning or deadlock because too long time waiting in >> interrupt context. >> + */ >> + >> + if (pci_dev_is_disconnected(pdev)) >> + return; >> info = dev_iommu_priv_get(dev); >> if (!info || !info->ats_enabled) > > It's likely better to check the device status after verifying > ats_enabled. How about below change? > > diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c > index 74e8e4c17e81..fa19c6cdfd8b 100644 > --- a/drivers/iommu/intel/pasid.c > +++ b/drivers/iommu/intel/pasid.c > @@ -481,6 +481,9 @@ devtlb_invalidation_with_pasid(struct intel_iommu > *iommu, > if (!info || !info->ats_enabled) > return; > > + if (pci_dev_is_disconnected(to_pci_dev(dev))) I like this kind of simplicity, but rationalist always brings me back to the no-error(ugly) style. :) Thanks, Ethan > + return > + > sid = info->bus << 8 | info->devfn; > qdep = info->ats_qdep; > pfsid = info->pfsid; > > Best regards, > baolu >
On 2023/12/19 14:49, Ethan Zhao wrote: >>> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c >>> index 74e8e4c17e81..182eb5df244d 100644 >>> --- a/drivers/iommu/intel/pasid.c >>> +++ b/drivers/iommu/intel/pasid.c >>> @@ -476,6 +476,23 @@ devtlb_invalidation_with_pasid(struct >>> intel_iommu *iommu, >>> { >>> struct device_domain_info *info; >>> u16 sid, qdep, pfsid; >>> + struct pci_dev *pdev; >>> + >>> + pdev = to_pci_dev(dev); >>> + if (!pdev) >>> + return; >>> + >>> + /* >>> + * If endpoint device's link was brough down by user's pci >>> configuration >>> + * access to it's hotplug capable slot link control register, as >>> sequence >>> + * response for DLLSC, pciehp_ist() will set the device >>> error_state to >>> + * pci_channel_io_perm_failure. Checking device's state here to >>> avoid >>> + * issuing meaningless devTLB flush request to it, that might >>> cause lockup >>> + * warning or deadlock because too long time waiting in >>> interrupt context. >>> + */ >>> + >>> + if (pci_dev_is_disconnected(pdev)) >>> + return; >>> info = dev_iommu_priv_get(dev); >>> if (!info || !info->ats_enabled) >> >> It's likely better to check the device status after verifying >> ats_enabled. How about below change? >> >> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c >> index 74e8e4c17e81..fa19c6cdfd8b 100644 >> --- a/drivers/iommu/intel/pasid.c >> +++ b/drivers/iommu/intel/pasid.c >> @@ -481,6 +481,9 @@ devtlb_invalidation_with_pasid(struct intel_iommu >> *iommu, >> if (!info || !info->ats_enabled) >> return; >> >> + if (pci_dev_is_disconnected(to_pci_dev(dev))) > > I like this kind of simplicity, but rationalist always brings me back to > the no-error(ugly) > > style. 🙂 The rational is that Intel IOMMU driver only supports PCI ATS. So if device is marked as ATS supported, then it must be a PCI device. Therefore, it's safe to convert it to pci_device with to_pci_dev(). If you move this up before ATS checking, then you need to check dev_is_pci(). Best regards, baolu
On 12/19/2023 2:57 PM, Baolu Lu wrote: > On 2023/12/19 14:49, Ethan Zhao wrote: >>>> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c >>>> index 74e8e4c17e81..182eb5df244d 100644 >>>> --- a/drivers/iommu/intel/pasid.c >>>> +++ b/drivers/iommu/intel/pasid.c >>>> @@ -476,6 +476,23 @@ devtlb_invalidation_with_pasid(struct >>>> intel_iommu *iommu, >>>> { >>>> struct device_domain_info *info; >>>> u16 sid, qdep, pfsid; >>>> + struct pci_dev *pdev; >>>> + >>>> + pdev = to_pci_dev(dev); >>>> + if (!pdev) >>>> + return; >>>> + >>>> + /* >>>> + * If endpoint device's link was brough down by user's pci >>>> configuration >>>> + * access to it's hotplug capable slot link control register, >>>> as sequence >>>> + * response for DLLSC, pciehp_ist() will set the device >>>> error_state to >>>> + * pci_channel_io_perm_failure. Checking device's state here >>>> to avoid >>>> + * issuing meaningless devTLB flush request to it, that might >>>> cause lockup >>>> + * warning or deadlock because too long time waiting in >>>> interrupt context. >>>> + */ >>>> + >>>> + if (pci_dev_is_disconnected(pdev)) >>>> + return; >>>> info = dev_iommu_priv_get(dev); >>>> if (!info || !info->ats_enabled) >>> >>> It's likely better to check the device status after verifying >>> ats_enabled. How about below change? >>> >>> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c >>> index 74e8e4c17e81..fa19c6cdfd8b 100644 >>> --- a/drivers/iommu/intel/pasid.c >>> +++ b/drivers/iommu/intel/pasid.c >>> @@ -481,6 +481,9 @@ devtlb_invalidation_with_pasid(struct >>> intel_iommu *iommu, >>> if (!info || !info->ats_enabled) >>> return; >>> >>> + if (pci_dev_is_disconnected(to_pci_dev(dev))) >> >> I like this kind of simplicity, but rationalist always brings me back >> to the no-error(ugly) >> >> style. 🙂 > > The rational is that Intel IOMMU driver only supports PCI ATS. So if > device is marked as ATS supported, then it must be a PCI device. > Therefore, it's safe to convert it to pci_device with to_pci_dev(). Fair engough ! Thanks, Ethan > > If you move this up before ATS checking, then you need to check > dev_is_pci(). > > Best regards, > baolu >
Baolu, On 12/19/2023 3:16 PM, Ethan Zhao wrote: > > On 12/19/2023 2:57 PM, Baolu Lu wrote: >> On 2023/12/19 14:49, Ethan Zhao wrote: >>>>> diff --git a/drivers/iommu/intel/pasid.c >>>>> b/drivers/iommu/intel/pasid.c >>>>> index 74e8e4c17e81..182eb5df244d 100644 >>>>> --- a/drivers/iommu/intel/pasid.c >>>>> +++ b/drivers/iommu/intel/pasid.c >>>>> @@ -476,6 +476,23 @@ devtlb_invalidation_with_pasid(struct >>>>> intel_iommu *iommu, >>>>> { >>>>> struct device_domain_info *info; >>>>> u16 sid, qdep, pfsid; >>>>> + struct pci_dev *pdev; >>>>> + >>>>> + pdev = to_pci_dev(dev); >>>>> + if (!pdev) >>>>> + return; >>>>> + >>>>> + /* >>>>> + * If endpoint device's link was brough down by user's pci >>>>> configuration >>>>> + * access to it's hotplug capable slot link control register, >>>>> as sequence >>>>> + * response for DLLSC, pciehp_ist() will set the device >>>>> error_state to >>>>> + * pci_channel_io_perm_failure. Checking device's state here >>>>> to avoid >>>>> + * issuing meaningless devTLB flush request to it, that might >>>>> cause lockup >>>>> + * warning or deadlock because too long time waiting in >>>>> interrupt context. >>>>> + */ >>>>> + >>>>> + if (pci_dev_is_disconnected(pdev)) >>>>> + return; >>>>> info = dev_iommu_priv_get(dev); >>>>> if (!info || !info->ats_enabled) >>>> >>>> It's likely better to check the device status after verifying >>>> ats_enabled. How about below change? >>>> >>>> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c >>>> index 74e8e4c17e81..fa19c6cdfd8b 100644 >>>> --- a/drivers/iommu/intel/pasid.c >>>> +++ b/drivers/iommu/intel/pasid.c >>>> @@ -481,6 +481,9 @@ devtlb_invalidation_with_pasid(struct >>>> intel_iommu *iommu, >>>> if (!info || !info->ats_enabled) >>>> return; >>>> >>>> + if (pci_dev_is_disconnected(to_pci_dev(dev))) >>> >>> I like this kind of simplicity, but rationalist always brings me >>> back to the no-error(ugly) >>> >>> style. 🙂 >> >> The rational is that Intel IOMMU driver only supports PCI ATS. So if >> device is marked as ATS supported, then it must be a PCI device. >> Therefore, it's safe to convert it to pci_device with to_pci_dev(). > > Fair engough ! > > May I use your reviewed-by sign in next version after that ? Thanks, Ethan > Thanks, > > Ethan > >> >> If you move this up before ATS checking, then you need to check >> dev_is_pci(). >> >> Best regards, >> baolu >> >
On 2023/12/19 15:27, Ethan Zhao wrote: > Baolu, > > On 12/19/2023 3:16 PM, Ethan Zhao wrote: >> >> On 12/19/2023 2:57 PM, Baolu Lu wrote: >>> On 2023/12/19 14:49, Ethan Zhao wrote: >>>>>> diff --git a/drivers/iommu/intel/pasid.c >>>>>> b/drivers/iommu/intel/pasid.c >>>>>> index 74e8e4c17e81..182eb5df244d 100644 >>>>>> --- a/drivers/iommu/intel/pasid.c >>>>>> +++ b/drivers/iommu/intel/pasid.c >>>>>> @@ -476,6 +476,23 @@ devtlb_invalidation_with_pasid(struct >>>>>> intel_iommu *iommu, >>>>>> { >>>>>> struct device_domain_info *info; >>>>>> u16 sid, qdep, pfsid; >>>>>> + struct pci_dev *pdev; >>>>>> + >>>>>> + pdev = to_pci_dev(dev); >>>>>> + if (!pdev) >>>>>> + return; >>>>>> + >>>>>> + /* >>>>>> + * If endpoint device's link was brough down by user's pci >>>>>> configuration >>>>>> + * access to it's hotplug capable slot link control register, >>>>>> as sequence >>>>>> + * response for DLLSC, pciehp_ist() will set the device >>>>>> error_state to >>>>>> + * pci_channel_io_perm_failure. Checking device's state here >>>>>> to avoid >>>>>> + * issuing meaningless devTLB flush request to it, that might >>>>>> cause lockup >>>>>> + * warning or deadlock because too long time waiting in >>>>>> interrupt context. >>>>>> + */ >>>>>> + >>>>>> + if (pci_dev_is_disconnected(pdev)) >>>>>> + return; >>>>>> info = dev_iommu_priv_get(dev); >>>>>> if (!info || !info->ats_enabled) >>>>> >>>>> It's likely better to check the device status after verifying >>>>> ats_enabled. How about below change? >>>>> >>>>> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c >>>>> index 74e8e4c17e81..fa19c6cdfd8b 100644 >>>>> --- a/drivers/iommu/intel/pasid.c >>>>> +++ b/drivers/iommu/intel/pasid.c >>>>> @@ -481,6 +481,9 @@ devtlb_invalidation_with_pasid(struct >>>>> intel_iommu *iommu, >>>>> if (!info || !info->ats_enabled) >>>>> return; >>>>> >>>>> + if (pci_dev_is_disconnected(to_pci_dev(dev))) >>>> >>>> I like this kind of simplicity, but rationalist always brings me >>>> back to the no-error(ugly) >>>> >>>> style. 🙂 >>> >>> The rational is that Intel IOMMU driver only supports PCI ATS. So if >>> device is marked as ATS supported, then it must be a PCI device. >>> Therefore, it's safe to convert it to pci_device with to_pci_dev(). >> >> Fair engough ! >> >> > May I use your reviewed-by sign in next version after that ? I am not sure about the changes in the PCI subsystem. Since the code here calls the new interface from that subsystem, I need acked-by on that change before proceeding. Best regards, baolu
On 12/19/2023 3:35 PM, Baolu Lu wrote: > On 2023/12/19 15:27, Ethan Zhao wrote: >> Baolu, >> >> On 12/19/2023 3:16 PM, Ethan Zhao wrote: >>> >>> On 12/19/2023 2:57 PM, Baolu Lu wrote: >>>> On 2023/12/19 14:49, Ethan Zhao wrote: >>>>>>> diff --git a/drivers/iommu/intel/pasid.c >>>>>>> b/drivers/iommu/intel/pasid.c >>>>>>> index 74e8e4c17e81..182eb5df244d 100644 >>>>>>> --- a/drivers/iommu/intel/pasid.c >>>>>>> +++ b/drivers/iommu/intel/pasid.c >>>>>>> @@ -476,6 +476,23 @@ devtlb_invalidation_with_pasid(struct >>>>>>> intel_iommu *iommu, >>>>>>> { >>>>>>> struct device_domain_info *info; >>>>>>> u16 sid, qdep, pfsid; >>>>>>> + struct pci_dev *pdev; >>>>>>> + >>>>>>> + pdev = to_pci_dev(dev); >>>>>>> + if (!pdev) >>>>>>> + return; >>>>>>> + >>>>>>> + /* >>>>>>> + * If endpoint device's link was brough down by user's pci >>>>>>> configuration >>>>>>> + * access to it's hotplug capable slot link control >>>>>>> register, as sequence >>>>>>> + * response for DLLSC, pciehp_ist() will set the device >>>>>>> error_state to >>>>>>> + * pci_channel_io_perm_failure. Checking device's state >>>>>>> here to avoid >>>>>>> + * issuing meaningless devTLB flush request to it, that >>>>>>> might cause lockup >>>>>>> + * warning or deadlock because too long time waiting in >>>>>>> interrupt context. >>>>>>> + */ >>>>>>> + >>>>>>> + if (pci_dev_is_disconnected(pdev)) >>>>>>> + return; >>>>>>> info = dev_iommu_priv_get(dev); >>>>>>> if (!info || !info->ats_enabled) >>>>>> >>>>>> It's likely better to check the device status after verifying >>>>>> ats_enabled. How about below change? >>>>>> >>>>>> diff --git a/drivers/iommu/intel/pasid.c >>>>>> b/drivers/iommu/intel/pasid.c >>>>>> index 74e8e4c17e81..fa19c6cdfd8b 100644 >>>>>> --- a/drivers/iommu/intel/pasid.c >>>>>> +++ b/drivers/iommu/intel/pasid.c >>>>>> @@ -481,6 +481,9 @@ devtlb_invalidation_with_pasid(struct >>>>>> intel_iommu *iommu, >>>>>> if (!info || !info->ats_enabled) >>>>>> return; >>>>>> >>>>>> + if (pci_dev_is_disconnected(to_pci_dev(dev))) >>>>> >>>>> I like this kind of simplicity, but rationalist always brings me >>>>> back to the no-error(ugly) >>>>> >>>>> style. 🙂 >>>> >>>> The rational is that Intel IOMMU driver only supports PCI ATS. So if >>>> device is marked as ATS supported, then it must be a PCI device. >>>> Therefore, it's safe to convert it to pci_device with to_pci_dev(). >>> >>> Fair engough ! >>> >>> >> May I use your reviewed-by sign in next version after that ? > > I am not sure about the changes in the PCI subsystem. Since the code IC Thanks, Ethan > here calls the new interface from that subsystem, I need acked-by on > that change before proceeding. > > Best regards, > baolu
diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c index 74e8e4c17e81..182eb5df244d 100644 --- a/drivers/iommu/intel/pasid.c +++ b/drivers/iommu/intel/pasid.c @@ -476,6 +476,23 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iommu, { struct device_domain_info *info; u16 sid, qdep, pfsid; + struct pci_dev *pdev; + + pdev = to_pci_dev(dev); + if (!pdev) + return; + + /* + * If endpoint device's link was brough down by user's pci configuration + * access to it's hotplug capable slot link control register, as sequence + * response for DLLSC, pciehp_ist() will set the device error_state to + * pci_channel_io_perm_failure. Checking device's state here to avoid + * issuing meaningless devTLB flush request to it, that might cause lockup + * warning or deadlock because too long time waiting in interrupt context. + */ + + if (pci_dev_is_disconnected(pdev)) + return; info = dev_iommu_priv_get(dev); if (!info || !info->ats_enabled)