ozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-220161-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id YDrCKqYro2kSyywAYBR5ng
	(envelope-from <stable+bounces-220161-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:53:42 +0000
Return-path: <stable+bounces-220161-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Sat, 28 Feb 2026 17:53:42 +0000
Received: from sto.lore.kernel.org ([172.232.135.74])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-220161-hi=josie.lol@vger.kernel.org>)
	id 1vwOVa-0000000Dlxt-0DIE
	for hi@josie.lol;
	Sat, 28 Feb 2026 17:53:42 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sto.lore.kernel.org (Postfix) with ESMTP id 448C43114E38
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:45:24 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 484AE495534;
	Sat, 28 Feb 2026 17:34:29 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hWI/Fi4c"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 23E17495533;
	Sat, 28 Feb 2026 17:34:29 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1772300069; cv=none; b=FCLlgFzGVufEnUzRH4mRE04Ft5ml7uzyINEDm5UvIIkCDhvYNYA4HyuRgBsjrC7qTUXbQhmXiFNfS9eUm5B+Hc0RvlAvpJIbD/d5Cm2sdsL5vJIcg/NzAiIeIidegk5nW2ioYFaSMNTQcwUSqbDnRX2zNpWnOVHltGKP5xzXBmY=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1772300069; c=relaxed/simple;
	bh=2pipMRddz6ailbs3zM8XCtd8z26OQ4v2LeH8oipn5UU=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=JHzvhsNZpWLbMSEaZlE3y/Y79ET0LIm0cvxFRA2iOdDgmjWV/idJiaB/le9KfbX+IQN461cIAG6SSTTF6KWZH1aZc3QC1D8TZxrN9Ds2GVIKgyD59GmTI8W2UpNc45r0YCl6Zjxrh0L0vJRVGEQNkLrXTxl20XxVaaGFk38G1mA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hWI/Fi4c; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71E94C4AF0B;
	Sat, 28 Feb 2026 17:34:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1772300069;
	bh=2pipMRddz6ailbs3zM8XCtd8z26OQ4v2LeH8oipn5UU=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=hWI/Fi4cHHU97E+Us3UEjdk28loRMIZCK9tKLGak7LC0jeO1ncqEpJQRRIXe16QeT
	 wCQn6ptnP2ZjdyGNnnCr71Qz1tWGT8k81K/r5NCGGJrDtMDMZFtNWA+gVyhNeI3S1u
	 MvMKySD9jrduVLlkMnCGeCKTzLmVRLSBUFM+C9Vw8YJbPLBAU6V8QUi4uz2IIF1ktd
	 Zj1cF2d6I4zDUe2dweNMzU5emxe0Rizkud1o4XkLqQMHpOIVrHX/lIWa7+Ivp7fINF
	 Vwi9IJ+QAsF+QM64rT4O1Fzm8jSov1llwaydVwf3Guqwlet0lHeSdm4blZKV0yTXiV
	 Ckmoj3F+sZuug==
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Yicong Yang <yang.yicong@picoheart.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.19 083/844] ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()
Date: Sat, 28 Feb 2026 12:19:56 -0500
Message-ID: <20260228173244.1509663-84-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org>
References: <20260228173244.1509663-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-DKIM: signer='kernel.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://docs.mxroute.com/docs/expert-spam-filtering.html
 ---
 Content analysis details:   (-1.2 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: msgid.link]
  0.0 URIBL_DBL_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             dbl.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: msgid.link]
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.232.135.74 listed in zen.spamhaus.org]
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.232.135.74 listed in list.dnswl.org]
  0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             zen.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: msgid.link]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: -11

From: Yicong Yang <yang.yicong@picoheart.com>

[ Upstream commit 7cf28b3797a81b616bb7eb3e90cf131afc452919 ]

The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a
system workqueue which is not guaranteed to be finished before entering
userspace. This may cause some key devices to be missing when userspace
init task tries to find them. Two issues observed on RISCV platforms:

 - Kernel panic due to userspace init cannot have an opened
   console.

   The console device scanning is queued by acpi_scan_clear_dep_queue()
   and not finished by the time userspace init process running, thus by
   the time userspace init runs, no console is present.

 - Entering rescue shell due to the lack of root devices (PCIe nvme in
   our case).

   Same reason as above, the PCIe host bridge scanning is queued on
   a system workqueue and finished after init process runs.

The reason is because both devices (console, PCIe host bridge) depend on
riscv-aplic irqchip to serve their interrupts (console's wired interrupt
and PCI's INTx interrupts). In order to keep the dependency, these
devices are scanned and created after initializing riscv-aplic. The
riscv-aplic is initialized in device_initcall() and a device scan work
is queued via acpi_scan_clear_dep_queue(), which is close to the time
userspace init process is run. Since system_dfl_wq is used in
acpi_scan_clear_dep_queue() with no synchronization, the issues will
happen if userspace init runs before these devices are ready.

The solution is to wait for the queued work to complete before entering
userspace init. One possible way would be to use a dedicated workqueue
instead of system_dfl_wq, and explicitly flush it somewhere in the
initcall stage before entering userspace. Another way is to use
async_schedule_dev_nocall() for scanning these devices. It's designed
for asynchronous initialization and will work in the same way as before
because it's using a dedicated unbound workqueue as well, but the kernel
init code calls async_synchronize_full() right before entering userspace
init which will wait for the work to complete.

Compared to a dedicated workqueue, the second approach is simpler
because the async schedule framework takes care of all of the details.
The ACPI code only needs to focus on its job. A dedicated workqueue for
this could also be redundant because some platforms don't need
acpi_scan_clear_dep_queue() for their device scanning.

Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
[ rjw: Subject adjustment, changelog edits ]
Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/acpi/scan.c | 41 +++++++++++++++--------------------------
 1 file changed, 15 insertions(+), 26 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 416d87f9bd107..b78f6be2f9468 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -5,6 +5,7 @@
 
 #define pr_fmt(fmt) "ACPI: " fmt
 
+#include <linux/async.h>
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/slab.h>
@@ -2360,46 +2361,34 @@ static int acpi_dev_get_next_consumer_dev_cb(struct acpi_dep_data *dep, void *da
 	return 0;
 }
 
-struct acpi_scan_clear_dep_work {
-	struct work_struct work;
-	struct acpi_device *adev;
-};
-
-static void acpi_scan_clear_dep_fn(struct work_struct *work)
+static void acpi_scan_clear_dep_fn(void *dev, async_cookie_t cookie)
 {
-	struct acpi_scan_clear_dep_work *cdw;
-
-	cdw = container_of(work, struct acpi_scan_clear_dep_work, work);
+	struct acpi_device *adev = to_acpi_device(dev);
 
 	acpi_scan_lock_acquire();
-	acpi_bus_attach(cdw->adev, (void *)true);
+	acpi_bus_attach(adev, (void *)true);
 	acpi_scan_lock_release();
 
-	acpi_dev_put(cdw->adev);
-	kfree(cdw);
+	acpi_dev_put(adev);
 }
 
 static bool acpi_scan_clear_dep_queue(struct acpi_device *adev)
 {
-	struct acpi_scan_clear_dep_work *cdw;
-
 	if (adev->dep_unmet)
 		return false;
 
-	cdw = kmalloc(sizeof(*cdw), GFP_KERNEL);
-	if (!cdw)
-		return false;
-
-	cdw->adev = adev;
-	INIT_WORK(&cdw->work, acpi_scan_clear_dep_fn);
 	/*
-	 * Since the work function may block on the lock until the entire
-	 * initial enumeration of devices is complete, put it into the unbound
-	 * workqueue.
+	 * Async schedule the deferred acpi_scan_clear_dep_fn() since:
+	 * - acpi_bus_attach() needs to hold acpi_scan_lock which cannot
+	 *   be acquired under acpi_dep_list_lock (held here)
+	 * - the deferred work at boot stage is ensured to be finished
+	 *   before userspace init task by the async_synchronize_full()
+	 *   barrier
+	 *
+	 * Use _nocall variant since it'll return on failure instead of
+	 * run the function synchronously.
 	 */
-	queue_work(system_dfl_wq, &cdw->work);
-
-	return true;
+	return async_schedule_dev_nocall(acpi_scan_clear_dep_fn, &adev->dev);
 }
 
 static void acpi_scan_delete_dep_data(struct acpi_dep_data *dep)
-- 
2.51.0



From - Sat Feb 28 17:53:47 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-220202-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id eMlHMKYro2kQyywAYBR5ng
	(envelope-from <stable+bounces-220202-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:53:42 +0000
Return-path: <stable+bounces-220202-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Sat, 28 Feb 2026 17:53:43 +0000
Received: from sea.lore.kernel.org ([172.234.253.10])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-220202-hi=josie.lol@vger.kernel.org>)
	id 1vwOVa-0000000Dly4-0QA5
	for hi@josie.lol;
	Sat, 28 Feb 2026 17:53:42 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sea.lore.kernel.org (Postfix) with ESMTP id 767BD308BCF4
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:52:58 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 33E3433FE27;
	Sat, 28 Feb 2026 17:35:08 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rf39c5oy"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 0F28C4D8D87;
	Sat, 28 Feb 2026 17:35:08 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1772300108; cv=none; b=BJAmfZAeJ5UdDSbR0uRakeXag/d4/PlYMb03FR645ElhLDJtEBxm4QTpYL6D2XT7qiG8loYuwyl4xCvnoekrC40ABL2PRyLNEXPjKk02T1qGZexAba21UVuC2vh6PvyQOOczF1E5m1oOpWj0m0ih3lMKihldReOblO7Y+PMfPrk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1772300108; c=relaxed/simple;
	bh=V/p2T36y6sxgHGYF7MNGfb1Sl2dsCVVYF9H5KcDeDcs=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=o9J2zcptqvhBGNFO1ZZui6UG8Jhqlrwiz9LqHWm0Zu6m5XpwoqO+tLkueGPTMR4G20WgF8sXIfCvSMxpbYTX3SkldHV2WgiXt4kaqspIId79aXMewO/t78nlY03X8ijtkHbK+J8nAWnSDuyEqw0qxHkFAQ/7I6q6h0MxQKOZcmY=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rf39c5oy; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42D8CC19424;
	Sat, 28 Feb 2026 17:35:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1772300107;
	bh=V/p2T36y6sxgHGYF7MNGfb1Sl2dsCVVYF9H5KcDeDcs=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=rf39c5oyim/4AyN3Jhljd3+MWyJqnt0uPT7IaHjuK8Mcp7gt4bpvAe42piLsTI/1T
	 hD6lA3UcxZH0Q+KVbk8M5RFQfyFZl8msmbecPEBAkBvYyjHhj7CihVaDEgX+9eVm/i
	 6domWo8isVa84NTG4zrxvXaM/VLMLj9YS6v+e2eEumht5/yHtYrwaiiMWyVC8NTpDJ
	 hERLrfTIoFBhsqQgSjB9sIvp3uZWq6qXmv280iIaRgduXuvTIA1v6vx8jef0NWDAnG
	 gbZAFZvutz+hxa9lAD32GC1QkAfOmskQygj/kKVyOWMMmMJsleVDbqI7vAzeBcG6v7
	 rYh0i2kAXkVSw==
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>,
	Matthew Brost <matthew.brost@intel.com>,
	=?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.19 124/844] drm/xe/vm: Skip ufence association for CPU address mirror VMA during MAP
Date: Sat, 28 Feb 2026 12:20:37 -0500
Message-ID: <20260228173244.1509663-125-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org>
References: <20260228173244.1509663-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-DKIM: signer='kernel.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://docs.mxroute.com/docs/expert-spam-filtering.html
 ---
 Content analysis details:   (-1.2 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: msgid.link]
  0.0 URIBL_DBL_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             dbl.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: msgid.link]
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.234.253.10 listed in zen.spamhaus.org]
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.234.253.10 listed in list.dnswl.org]
  0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             zen.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: msgid.link]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: -11

From: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>

[ Upstream commit 7f08cc5b3cc3bf6416f8b55bff906f67ed75637d ]

The MAP operation for a CPU address mirror VMA does not require ufence
association because such mappings are not GPU-synchronized and do not
participate in GPU job completion signaling.

Remove the unnecessary ufence addition for this case to avoid -EBUSY
failure in check_ufence of unbind ops.

Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20251125075628.1182481-6-himal.prasad.ghimiray@intel.com
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/xe/xe_vm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
index 9781209dd26ed..612fc5b2539cd 100644
--- a/drivers/gpu/drm/xe/xe_vm.c
+++ b/drivers/gpu/drm/xe/xe_vm.c
@@ -3223,7 +3223,8 @@ static void op_add_ufence(struct xe_vm *vm, struct xe_vma_op *op,
 {
 	switch (op->base.op) {
 	case DRM_GPUVA_OP_MAP:
-		vma_add_ufence(op->map.vma, ufence);
+		if (!xe_vma_is_cpu_addr_mirror(op->map.vma))
+			vma_add_ufence(op->map.vma, ufence);
 		break;
 	case DRM_GPUVA_OP_REMAP:
 		if (op->remap.prev)
-- 
2.51.0



From - Sat Feb 28 17:53:59 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-220124-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id 0CnJI7Iro2kRtjAAYBR5ng
	(envelope-from <stable+bounces-220124-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:53:54 +0000
Return-path: <stable+bounces-220124-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Sat, 28 Feb 2026 17:53:54 +0000
Received: from sin.lore.kernel.org ([104.64.211.4])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-220124-hi=josie.lol@vger.kernel.org>)
	id 1vwOVl-0000000DmJq-39Dq
	for hi@josie.lol;
	Sat, 28 Feb 2026 17:53:54 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sin.lore.kernel.org (Postfix) with ESMTP id 835A830BFECC
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:38:35 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 9B56648097A;
	Sat, 28 Feb 2026 17:33:54 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a0hA44KW"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 765CA480DE0;
	Sat, 28 Feb 2026 17:33:54 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1772300034; cv=none; b=CLm7N3MsO698H3JwJfrf4+HB8/2lA5gcCLoGexUvtu/yfnktkdAzIJX8B/vsWh5iHhO1JnJXhvwng+vySJfGMNtholNsRKj6X9ZHXlYvp6gEwP9gZ+Vqiyj/uMlg0zaP37pusuPuEzJFmraF0WWelolimUEy6+98OI65/6hqDrQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1772300034; c=relaxed/simple;
	bh=S8OInPU44O8H08ja7d4spf82h8LMrpkcMHwGprFpQ4Q=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=TH9J6P8aMaGuI2rjx+qee0m4+gE9jrqmZHbYcrGtiAMzENy34HLsOOShP0G676REQSHdLO5p4pOxYy2oqHPzOYDqcwU3f99eoC6+IWnMqqWP7MWEBivC+c2J7OmK8DE5n7uupR3FBjwwIO5cYIZa/0AkYNxidyTBtDfPQQh4MD0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a0hA44KW; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C08B0C116D0;
	Sat, 28 Feb 2026 17:33:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1772300034;
	bh=S8OInPU44O8H08ja7d4spf82h8LMrpkcMHwGprFpQ4Q=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=a0hA44KW+XS/JXgiHvPshwIMGx4GBBUAgGG4Vxic/l09LtGdy/LNJSTk2j3+kMRk1
	 /+IAoSQtMeHXeqAaFp9v5QLWV+wmZCGc21Om5k4m29U0iiYk2Np7pP59RAsz87b4P3
	 OUK/oSWCZuZPGClQfle8dpa/mqnsg1WtFePG/+/UCj2804Ml8ifTZau2T5r1GGtUY4
	 OH86lNH/+7PYT75MYL7CXJpBQWUpPd4nRtVcOMCnn7L2y+5MYk/6h++ajdR2L2N69+
	 +eY+FUd36+5rrNN/lBpHUNmmaV26mTM2tusLi+yPqPYcaJ8x/c5iFd/0WoFErtrJAl
	 LboekIr4dtAyw==
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Alexander Aring <aahringo@redhat.com>,
	David Teigland <teigland@redhat.com>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.19 046/844] dlm: fix recovery pending middle conversion
Date: Sat, 28 Feb 2026 12:19:19 -0500
Message-ID: <20260228173244.1509663-47-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org>
References: <20260228173244.1509663-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-DKIM: signer='kernel.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://docs.mxroute.com/docs/expert-spam-filtering.html
 ---
 Content analysis details:   (-1.2 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [104.64.211.4 listed in zen.spamhaus.org]
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [104.64.211.4 listed in list.dnswl.org]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: -11

From: Alexander Aring <aahringo@redhat.com>

[ Upstream commit 1416bd508c78bdfdb9ae0b4511369e5581f348ea ]

During a workload involving conversions between lock modes PR and CW,
lock recovery can create a "conversion deadlock" state between locks
that have been recovered.  When this occurs, kernel warning messages
are logged, e.g.

  "dlm: WARN: pending deadlock 1e node 0 2 1bf21"

  "dlm: receive_rcom_lock_args 2e middle convert gr 3 rq 2 remote 2 1e"

After this occurs, the deadlocked conversions both appear on the convert
queue of the resource being locked, and the conversion requests do not
complete.

Outside of recovery, conversions that would produce a deadlock are
resolved immediately, and return -EDEADLK.  The locks are not placed
on the convert queue in the deadlocked state.

To fix this problem, an lkb under conversion between PR/CW is rebuilt
during recovery on a new master's granted queue, with the currently
granted mode, rather than being rebuilt on the new master's convert
queue, with the currently granted mode and the newly requested mode.
The in-progress convert is then resent to the new master after
recovery, so the conversion deadlock will be processed outside of
the recovery context and handled as described above.

Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/dlm/lock.c | 19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
index be938fdf17d96..c01a291db401b 100644
--- a/fs/dlm/lock.c
+++ b/fs/dlm/lock.c
@@ -5014,25 +5014,8 @@ void dlm_receive_buffer(const union dlm_packet *p, int nodeid)
 static void recover_convert_waiter(struct dlm_ls *ls, struct dlm_lkb *lkb,
 				   struct dlm_message *ms_local)
 {
-	if (middle_conversion(lkb)) {
-		log_rinfo(ls, "%s %x middle convert in progress", __func__,
-			 lkb->lkb_id);
-
-		/* We sent this lock to the new master. The new master will
-		 * tell us when it's granted.  We no longer need a reply, so
-		 * use a fake reply to put the lkb into the right state.
-		 */
-		hold_lkb(lkb);
-		memset(ms_local, 0, sizeof(struct dlm_message));
-		ms_local->m_type = cpu_to_le32(DLM_MSG_CONVERT_REPLY);
-		ms_local->m_result = cpu_to_le32(to_dlm_errno(-EINPROGRESS));
-		ms_local->m_header.h_nodeid = cpu_to_le32(lkb->lkb_nodeid);
-		_receive_convert_reply(lkb, ms_local, true);
-		unhold_lkb(lkb);
-
-	} else if (lkb->lkb_rqmode >= lkb->lkb_grmode) {
+	if (middle_conversion(lkb) || lkb->lkb_rqmode >= lkb->lkb_grmode)
 		set_bit(DLM_IFL_RESEND_BIT, &lkb->lkb_iflags);
-	}
 
 	/* lkb->lkb_rqmode < lkb->lkb_grmode shouldn't happen since down
 	   conversions are async; there's no reply from the remote master */
-- 
2.51.0



From - Sat Feb 28 17:54:04 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-220166-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id 6IyvIbgro2lDXisAYBR5ng
	(envelope-from <stable+bounces-220166-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:54:00 +0000
Return-path: <stable+bounces-220166-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Sat, 28 Feb 2026 17:54:00 +0000
Received: from sto.lore.kernel.org ([172.232.135.74])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-220166-hi=josie.lol@vger.kernel.org>)
	id 1vwOVr-0000000DmdA-49CI
	for hi@josie.lol;
	Sat, 28 Feb 2026 17:54:00 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sto.lore.kernel.org (Postfix) with ESMTP id EC5083126D21
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:46:22 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 1E72F49690C;
	Sat, 28 Feb 2026 17:34:34 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qg7ZG1E2"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 EED97496908;
	Sat, 28 Feb 2026 17:34:33 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1772300074; cv=none; b=ZYyrjjK5cD7nAmvwvM+uWMBzhwbSGBOUcAMLIlN5IHlSVRzmpbWKo3EW/AhM0NW9aF+aM9OB+maOg+EKncWMg6afMqNczgtYX98HrBhB0XKMMlqou2DXlgcSh4BFZK3K0JL6H2aJ4nNKQikTzv5sZxm1whpBv6w9BiuT5ISLGHE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1772300074; c=relaxed/simple;
	bh=JqjnUMKlVgixfHjEdpBSAggZsMoLdZspUbOL62UOxns=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=UvDpOsLenOv8LpHWql4smI5tXMYppFkTH6AaWJppTba+AljYyHQvS5A3qdgDb/KbtM6DHk+DCvhOX7UQNnvZczhdcqp/DlY/HxwfQrOKjy2wFnZ0D4lXTUZx6Rp97ZhXbY53rID9K5RNnhyIZLsOBifR6u1P0Ror0ALZ7Xr8z9g=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qg7ZG1E2; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 309BFC19425;
	Sat, 28 Feb 2026 17:34:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1772300073;
	bh=JqjnUMKlVgixfHjEdpBSAggZsMoLdZspUbOL62UOxns=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=qg7ZG1E2saEPW3niEDpZ3fgZx0yxac4NY73887q1z7KrgnNNHhYDAmA2B3J2ecsTd
	 Eh6Dy5pf8DuaC7QDuVr1JkuWePCsUY7P3X/SbSZVfcdq9ThO7Xj/FAgcgfaJXyJUcZ
	 h35NzTOvFdRyCEMj1T1gDtWcrw05ciNBsDxNfUPG/qy/WOxToSDC4jFJk3WeFHH0Kf
	 /eOdclNhIBL8LqpuzeW4BYXGy56ojRKYysCq1vB307EesjnqosUe0515t+NC2Tktdt
	 T8YBkGYPBC+B6/dW6s58NfQqxJSeDtrIwy60AUhC6U41vdY+FkvNF175MMZakDK997
	 NJeWCEOp/6mfw==
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Luke Wang <ziniu.wang_1@nxp.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Jens Axboe <axboe@kernel.dk>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.19 088/844] block: decouple secure erase size limit from discard size limit
Date: Sat, 28 Feb 2026 12:20:01 -0500
Message-ID: <20260228173244.1509663-89-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org>
References: <20260228173244.1509663-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-DKIM: signer='kernel.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://docs.mxroute.com/docs/expert-spam-filtering.html
 ---
 Content analysis details:   (-1.2 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.232.135.74 listed in zen.spamhaus.org]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: -11

From: Luke Wang <ziniu.wang_1@nxp.com>

[ Upstream commit ee81212f74a57c5d2b56cf504f40d528dac6faaf ]

Secure erase should use max_secure_erase_sectors instead of being limited
by max_discard_sectors. Separate the handling of REQ_OP_SECURE_ERASE from
REQ_OP_DISCARD to allow each operation to use its own size limit.

Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 block/blk-merge.c | 21 +++++++++++++++++----
 block/blk.h       |  6 +++++-
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index d3115d7469df0..bf8faadb0bd46 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -158,8 +158,9 @@ static struct bio *bio_submit_split(struct bio *bio, int split_sectors)
 	return bio;
 }
 
-struct bio *bio_split_discard(struct bio *bio, const struct queue_limits *lim,
-		unsigned *nsegs)
+static struct bio *__bio_split_discard(struct bio *bio,
+		const struct queue_limits *lim, unsigned *nsegs,
+		unsigned int max_sectors)
 {
 	unsigned int max_discard_sectors, granularity;
 	sector_t tmp;
@@ -169,8 +170,7 @@ struct bio *bio_split_discard(struct bio *bio, const struct queue_limits *lim,
 
 	granularity = max(lim->discard_granularity >> 9, 1U);
 
-	max_discard_sectors =
-		min(lim->max_discard_sectors, bio_allowed_max_sectors(lim));
+	max_discard_sectors = min(max_sectors, bio_allowed_max_sectors(lim));
 	max_discard_sectors -= max_discard_sectors % granularity;
 	if (unlikely(!max_discard_sectors))
 		return bio;
@@ -194,6 +194,19 @@ struct bio *bio_split_discard(struct bio *bio, const struct queue_limits *lim,
 	return bio_submit_split(bio, split_sectors);
 }
 
+struct bio *bio_split_discard(struct bio *bio, const struct queue_limits *lim,
+		unsigned *nsegs)
+{
+	unsigned int max_sectors;
+
+	if (bio_op(bio) == REQ_OP_SECURE_ERASE)
+		max_sectors = lim->max_secure_erase_sectors;
+	else
+		max_sectors = lim->max_discard_sectors;
+
+	return __bio_split_discard(bio, lim, nsegs, max_sectors);
+}
+
 static inline unsigned int blk_boundary_sectors(const struct queue_limits *lim,
 						bool is_atomic)
 {
diff --git a/block/blk.h b/block/blk.h
index e4c433f62dfc7..4cd5a91346d8a 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -208,10 +208,14 @@ static inline unsigned int blk_queue_get_max_sectors(struct request *rq)
 	struct request_queue *q = rq->q;
 	enum req_op op = req_op(rq);
 
-	if (unlikely(op == REQ_OP_DISCARD || op == REQ_OP_SECURE_ERASE))
+	if (unlikely(op == REQ_OP_DISCARD))
 		return min(q->limits.max_discard_sectors,
 			   UINT_MAX >> SECTOR_SHIFT);
 
+	if (unlikely(op == REQ_OP_SECURE_ERASE))
+		return min(q->limits.max_secure_erase_sectors,
+			   UINT_MAX >> SECTOR_SHIFT);
+
 	if (unlikely(op == REQ_OP_WRITE_ZEROES))
 		return q->limits.max_write_zeroes_sectors;
 
-- 
2.51.0



From - Sat Feb 28 17:54:20 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-220203-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id sIbeOscro2lDXisAYBR5ng
	(envelope-from <stable+bounces-220203-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:54:15 +0000
Return-path: <stable+bounces-220203-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Sat, 28 Feb 2026 17:54:16 +0000
Received: from sea.lore.kernel.org ([172.234.253.10])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-220203-hi=josie.lol@vger.kernel.org>)
	id 1vwOW7-0000000DnJB-1WOc
	for hi@josie.lol;
	Sat, 28 Feb 2026 17:54:15 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sea.lore.kernel.org (Postfix) with ESMTP id BE69F306248A
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:53:00 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 09D054D8D9E;
	Sat, 28 Feb 2026 17:35:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UIZRwC0u"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 DB6854D8D9C;
	Sat, 28 Feb 2026 17:35:08 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1772300108; cv=none; b=oEbJwf0cqdzV7TiFYvoxC6MsoK+NHRZ/CyZNcrXmPxRVJ2MXpClUBonUQqjAmT0HgGB5/SmuF42pxrdaB92equILwgVy6txVoiEWNHxVbWVk7XyOhzPR6ri633oWZgAcYQLTK6XHsFfUP05FZLyg3mImX++184cPM9p7IDwacf4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1772300108; c=relaxed/simple;
	bh=tBg3vpDSFHpRBvcSIvLKnAjE33wX6Eu8WWVlpec+G9A=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=k/keo7DtNX84j9OjIk3DHzYXGmPqCJugeIr9A1+qOTsyYJw9jeEFMyrpyJ7ZCsem5TDTa5ievOPH83SjZKE1yojnNTrnQj/kHGMjCIHI09UYnpv9X5M3KdqO9zGzFzAiuei0CN6f2IH+fTPbojtmZ6rKVM72ptAhfgTGsqfDQTo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UIZRwC0u; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34F03C116D0;
	Sat, 28 Feb 2026 17:35:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1772300108;
	bh=tBg3vpDSFHpRBvcSIvLKnAjE33wX6Eu8WWVlpec+G9A=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=UIZRwC0uJALE5lv3tH1CQOt6imtsAZlh2JJ862vk+jin4cjNYeLlibfev+cswkG3f
	 dlPPQ9/c4CDuMcXmJop+qkMVK4jKDhXwaBZqHpaROHlPTR64yTLPl6Ledsd9zlWkR6
	 3yZxz98Vo7bZP9izC035uVJkmR8XuXCuVGclkugkSOPSJ2h1nik80FOxBmi4352pdT
	 yfbH3Pln7oWk8ilZ2/+CFAicPse5VZ57WkNeJduFfRmp+ZCeEt+4ud9qsvDRBkR98e
	 yii6XVMJlxdDKT0WJJ7Lr+mWBut8T806LuXV/1TCluoFytfdCFWwyzRGBkPUi7rY7R
	 BDA7cjGWUUdvg==
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
	Steven Price <steven.price@arm.com>,
	Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.19 125/844] drm/panthor: Always wait after sending a command to an AS
Date: Sat, 28 Feb 2026 12:20:38 -0500
Message-ID: <20260228173244.1509663-126-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org>
References: <20260228173244.1509663-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: stable@vger.kernel.org
List-Id: <stable.vger.kernel.org>
List-Subscribe: <mailto:stable+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:stable+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
Content-Transfer-Encoding: 8bit
X-DKIM: signer='kernel.org' status='pass' reason=''
DKIMCheck: Server passes DKIM test, 0 Spam score
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has
 performed the tests listed below against this email.
 Information: https://docs.mxroute.com/docs/expert-spam-filtering.html
 ---
 Content analysis details:   (-1.2 points)
 ---
  pts rule name              description
 ---- ---------------------- -----------------------------------------
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: msgid.link]
  0.0 URIBL_DBL_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             dbl.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: msgid.link]
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.234.253.10 listed in zen.spamhaus.org]
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.234.253.10 listed in list.dnswl.org]
  0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             zen.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: msgid.link]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: -11

From: Boris Brezillon <boris.brezillon@collabora.com>

[ Upstream commit d2c6fde56d451ca48a5e03428535ce3dbc8fc910 ]

There's currently no situation where we want to issue a command to an
AS and not wait for this command to complete. The wait is either
explicitly done (LOCK, UNLOCK) or it's missing (UPDATE). So let's
turn write_cmd() into as_send_cmd_and_wait() that has the wait after
a command is sent.

v2:
- New patch

v3:
- Collect R-b

v4:
- No changes

Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20251128084841.3804658-2-boris.brezillon@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/panthor/panthor_mmu.c | 27 ++++++++++++---------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
index 9194bad4b6196..c15d2a3906db9 100644
--- a/drivers/gpu/drm/panthor/panthor_mmu.c
+++ b/drivers/gpu/drm/panthor/panthor_mmu.c
@@ -510,27 +510,29 @@ static int wait_ready(struct panthor_device *ptdev, u32 as_nr)
 	return ret;
 }
 
-static int write_cmd(struct panthor_device *ptdev, u32 as_nr, u32 cmd)
+static int as_send_cmd_and_wait(struct panthor_device *ptdev, u32 as_nr, u32 cmd)
 {
 	int status;
 
 	/* write AS_COMMAND when MMU is ready to accept another command */
 	status = wait_ready(ptdev, as_nr);
-	if (!status)
+	if (!status) {
 		gpu_write(ptdev, AS_COMMAND(as_nr), cmd);
+		status = wait_ready(ptdev, as_nr);
+	}
 
 	return status;
 }
 
-static void lock_region(struct panthor_device *ptdev, u32 as_nr,
-			u64 region_start, u64 size)
+static int lock_region(struct panthor_device *ptdev, u32 as_nr,
+		       u64 region_start, u64 size)
 {
 	u8 region_width;
 	u64 region;
 	u64 region_end = region_start + size;
 
 	if (!size)
-		return;
+		return 0;
 
 	/*
 	 * The locked region is a naturally aligned power of 2 block encoded as
@@ -553,7 +555,7 @@ static void lock_region(struct panthor_device *ptdev, u32 as_nr,
 
 	/* Lock the region that needs to be updated */
 	gpu_write64(ptdev, AS_LOCKADDR(as_nr), region);
-	write_cmd(ptdev, as_nr, AS_COMMAND_LOCK);
+	return as_send_cmd_and_wait(ptdev, as_nr, AS_COMMAND_LOCK);
 }
 
 static int mmu_hw_do_operation_locked(struct panthor_device *ptdev, int as_nr,
@@ -586,9 +588,7 @@ static int mmu_hw_do_operation_locked(struct panthor_device *ptdev, int as_nr,
 	 * power it up
 	 */
 
-	lock_region(ptdev, as_nr, iova, size);
-
-	ret = wait_ready(ptdev, as_nr);
+	ret = lock_region(ptdev, as_nr, iova, size);
 	if (ret)
 		return ret;
 
@@ -601,10 +601,7 @@ static int mmu_hw_do_operation_locked(struct panthor_device *ptdev, int as_nr,
 	 * at the end of the GPU_CONTROL cache flush command, unlike
 	 * AS_COMMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT.
 	 */
-	write_cmd(ptdev, as_nr, AS_COMMAND_UNLOCK);
-
-	/* Wait for the unlock command to complete */
-	return wait_ready(ptdev, as_nr);
+	return as_send_cmd_and_wait(ptdev, as_nr, AS_COMMAND_UNLOCK);
 }
 
 static int mmu_hw_do_operation(struct panthor_vm *vm,
@@ -633,7 +630,7 @@ static int panthor_mmu_as_enable(struct panthor_device *ptdev, u32 as_nr,
 	gpu_write64(ptdev, AS_MEMATTR(as_nr), memattr);
 	gpu_write64(ptdev, AS_TRANSCFG(as_nr), transcfg);
 
-	return write_cmd(ptdev, as_nr, AS_COMMAND_UPDATE);
+	return as_send_cmd_and_wait(ptdev, as_nr, AS_COMMAND_UPDATE);
 }
 
 static int panthor_mmu_as_disable(struct panthor_device *ptdev, u32 as_nr)
@@ -648,7 +645,7 @@ static int panthor_mmu_as_disable(struct panthor_device *ptdev, u32 as_nr)
 	gpu_write64(ptdev, AS_MEMATTR(as_nr), 0);
 	gpu_write64(ptdev, AS_TRANSCFG(as_nr), AS_TRANSCFG_ADRMODE_UNMAPPED);
 
-	return write_cmd(ptdev, as_nr, AS_COMMAND_UPDATE);
+	return as_send_cmd_and_wait(ptdev, as_nr, AS_COMMAND_UPDATE);
 }
 
 static u32 panthor_mmu_fault_mask(struct panthor_device *ptdev, u32 value)
-- 
2.51.0



From - Sat Feb 28 17:54:25 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-220170-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id cPnHHs0ro2lcczAAYBR5ng
	(envelope-from <stable+bounces-220170-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:54:21 +0000
Return-path: <stable+bounces-220170-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Sat, 28 Feb 2026 17:54:21 +0000
Received: from sto.lore.kernel.org ([172.232.135.74])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-220170-hi=josie.lol@vger.kernel.org>)
	id 1vwOWC-0000000DnWT-3vOw
	for hi@josie.lol;
	Sat, 28 Feb 2026 17:54:21 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sto.lore.kernel.org (Postfix) with ESMTP id E93C03140100
	for <hi@josie.lol>; Sat, 28 Feb 2026 17:47:12 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 7E1824A2E2C;
	Sat, 28 Feb 2026 17:34:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YDwFFHae"
X-Original-To: stable@vger.kernel.org
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 57C4E4A2E26;
	Sat, 28 Feb 2026 17:34:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1772300078; cv=none; b=EZaySM8++9aOyTjJgjHkb5yKuWojL32CNUOBCMzldHGHJInsp/IzVyRVNldRWwyNzSqyWJFE2sA8qLl3Z11KDZUtmLT4lCTMazh584+x5xvMal5BuLZSUy9c0sPKrbIxrzj/I7f70IfI9AUVMJ0JoMswTFgSpaCfZz0r/YdzQIQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1772300078; c=relaxed/simple;
	bh=2uN9iCK6tuGK6dMbwblD+HHT/IcSCyQZCs/7NUou670=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=ceGb9k8ImgBJhE9jeNwCUvYB8uBFM/Wj/fdYatpV4T/7t+MLCFQsVNAlJw1IA7jA1EHs6dQp72K2m03f7JnD/cCbLmC0vB45vai7Sklr3k93xIDfWzZrTBfJIPWCXVZ7EGCgfm63ObtQcEgyBM0FAYqEF6gqMJpIbwU3kYHST9Q=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YDwFFHae; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 492C0C2BC87;
	Sat, 28 Feb 2026 17:34:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1772300078;
	bh=2uN9iCK6tuGK6dMbwblD+HHT/IcSCyQZCs/7NUou670=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=YDwFFHaeyTgR78skJnEtFUt55xNJKhECYypVk6I3cpS54qdS+tDS4m1ImTnSdFA8p
	 /gICFvkIsThIDE5IhBUIPrie4rbQANYqEPId2C2FXF4HCgCDIITfCHumbJmhlCPrmE
	 7vw577AVVzmOzUUY6oA1HCMGum+9XZilo4ECBaXmTxxFhCdJmnHrqYVuyqolayPgAe
	 41uPphZx91+kamA8Lv3McSz1szjxwkYm8geWNSRy/pUp1OXKUsSs6IpWEKNmnhtEl5
	 KrnPRJr5MAznHrEdF0g9FjTBYwaKy/B1GH3mvYxrqSXwYY64MXgs72Ad9lWrOZ67e2
	 v1hsPpXgaZtVQ==
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Nick Hu <nick.hu@sifive.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Yong-Xuan Wang <yongxuan.wang