summaryrefslogtreecommitdiff
path: root/drivers/dma
diff options
context:
space:
mode:
authorYi Sun <yi.sun@intel.com>2025-05-09 08:03:04 +0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2025-07-06 11:00:06 +0200
commite0051a3daa8b2cb318b03b2f9317c3e40855847a (patch)
treebc9e14c4bbd697ddbc2f9a93d08744e92c5c3a83 /drivers/dma
parentc765f592adc719cd2b925b0f30d65207a7e8f8f5 (diff)
downloadlinux-e0051a3daa8b2cb318b03b2f9317c3e40855847a.tar.gz
linux-e0051a3daa8b2cb318b03b2f9317c3e40855847a.tar.bz2
linux-e0051a3daa8b2cb318b03b2f9317c3e40855847a.zip
dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using
[ Upstream commit 17502e7d7b7113346296f6758324798d536c31fd ] Running IDXD workloads in a container with the /dev directory mounted can trigger a call trace or even a kernel panic when the parent process of the container is terminated. This issue occurs because, under certain configurations, Docker does not properly propagate the mount replica back to the original mount point. In this case, when the user driver detaches, the WQ is destroyed but it still calls destroy_workqueue() attempting to completes all pending work. It's necessary to check wq->wq and skip the drain if it no longer exists. Signed-off-by: Yi Sun <yi.sun@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Link: https://lore.kernel.org/r/20250509000304.1402863-1-yi.sun@intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'drivers/dma')
-rw-r--r--drivers/dma/idxd/cdev.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/drivers/dma/idxd/cdev.c b/drivers/dma/idxd/cdev.c
index 7e3a67f9f0a6..aa39fcd389a9 100644
--- a/drivers/dma/idxd/cdev.c
+++ b/drivers/dma/idxd/cdev.c
@@ -354,7 +354,9 @@ static void idxd_cdev_evl_drain_pasid(struct idxd_wq *wq, u32 pasid)
set_bit(h, evl->bmap);
h = (h + 1) % size;
}
- drain_workqueue(wq->wq);
+ if (wq->wq)
+ drain_workqueue(wq->wq);
+
mutex_unlock(&evl->lock);
}