From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8D942C79F82 for ; Tue, 8 Sep 2026 17:23:36 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1F25D10E1A5; Tue, 8 Sep 2026 17:23:36 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="kaRSDZ06"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by gabe.freedesktop.org (Postfix) with ESMTPS id 364DF10E1A5 for ; Tue, 8 Sep 2026 17:23:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788888215; x=1820424215; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=50LqJ4sLn1G9RiMSyszMEM8JnlsfHvY4mihN8QV/IrQ=; b=kaRSDZ06mP2+2EdXQB1nYifVfyoojUsmvlqGZVeSNLZrhd+hJtb9yekc uPx+HiyzWbEZU7HX3Fxky2lqAMwqx57Cy0KH8NJjBugdLn3QTqdpU4SXv oIj5zfXpNF9bPZSqoZJmz5+fIdtqO0oEzfuxecH48pmhnKR1nVZo4YtVv zJ0AQ0sFEBsTibOZmrKE5u7/l9bpPKgmw0f4emSH3kLPWHrrqc1GMtKLN lW88wrl0MyZuOwDaUpQVVKYkWOedjzCTqBTrnY/esmCnmZjoVBFNUK0zs k0Zx2VRRCOPfLbjdX0ZZGpsCiGNkR+a+WU9cpiO32307Bdh+/Cuhj3hEM Q==; X-CSE-ConnectionGUID: tvgNmTOfTA+AqC3kwHan0Q== X-CSE-MsgGUID: HkcbHfFITs67lXdbL1T+kQ== X-IronPort-AV: E=McAfee;i="6800,10657,11900"; a="114838527" X-IronPort-AV: E=Sophos;i="6.25,269,1779174000"; d="scan'208";a="114838527" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2026 10:23:35 -0700 X-CSE-ConnectionGUID: DRBdbyydTsSqTubUpaUXNA== X-CSE-MsgGUID: B43g+XUtQ7GtI9gSpU/aig== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,269,1779174000"; d="scan'208";a="276304649" Received: from rvuia-mobl.ger.corp.intel.com (HELO [10.245.244.158]) ([10.245.244.158]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2026 10:23:34 -0700 Message-ID: <183c1f62-0193-41c5-b67f-a6e143ed933a@intel.com> Date: Tue, 8 Sep 2026 18:23:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 6/8] drm/xe/mmio_gem: fix destroy flow To: sashiko-reviews@lists.linux.dev Cc: intel-xe@lists.freedesktop.org References: <20260908165046.1393557-10-matthew.auld@intel.com> <20260908165046.1393557-16-matthew.auld@intel.com> <20260908171241.EE84B1F00A3F@smtp.kernel.org> Content-Language: en-GB From: Matthew Auld In-Reply-To: <20260908171241.EE84B1F00A3F@smtp.kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On 08/09/2026 18:12, sashiko-bot@kernel.org wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > > Pre-existing issues: > - [High] GFP_KERNEL allocation under dma_resv lock triggers lockdep splat and potential deadlock > -- > > commit 6f195ca9ff5839faa94b4a50effe5cb10176e87b > Author: Ilia Levi > Subject: drm/xe/mmio_gem: fix destroy flow > > This commit fixes a use-after-free in the gem object destroy flow by > introducing proper synchronization and refcounting. It uses the dma_resv lock > to serialize the fault handler with the destroy operation and unmaps existing > pages to cut off access to the real mmio after destruction. > >> diff --git a/drivers/gpu/drm/xe/xe_mmio_gem.c b/drivers/gpu/drm/xe/xe_mmio_gem.c >> index 970b1e2f49815..5ffe03d361902 100644 >> --- a/drivers/gpu/drm/xe/xe_mmio_gem.c >> +++ b/drivers/gpu/drm/xe/xe_mmio_gem.c > [ ... ] >> @@ -176,10 +189,9 @@ static int alloc_dummy_page_if_needed(struct drm_gem_object *base) >> { >> struct xe_mmio_gem *obj = to_xe_mmio_gem(base); >> >> - dma_resv_lock(base->resv, NULL); >> + dma_resv_assert_held(base->resv); >> if (!obj->dummy_page) >> obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO); > > [Severity: High] > This isn't a bug introduced by this patch, but does this allocation context > create a lockdep violation or potential deadlock? > > The vma fault handler calls xe_mmio_gem_vm_fault, which takes the > dma_resv_lock. If the device is unplugged, it eventually calls > alloc_dummy_page_if_needed, executing alloc_page(GFP_KERNEL | __GFP_ZERO) > while holding base->resv. Since dma_resv locks are taken by shrinkers during > memory reclaim, holding it while doing a GFP_KERNEL allocation creates a > circular dependency. We are allowed to allocate under dma-resv. Loads of places do it. From shrinker side, it is trylock all the way down for dma-resv, at least for direct-reclaim. > > This can be reached by any unprivileged userspace process that mmaps the mmio > gem object and triggers a page fault while the device is in an unplugged > state. > >> - dma_resv_unlock(base->resv); >> >> return obj->dummy_page ? 0 : -ENOMEM; >> } >