From nobody Fri Sep 25 10:36:35 2026 Received: from mail-wm2-f12.google.com (mail-wm2-f12.google.com [74.125.225.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 525EE3F482F for ; Mon, 14 Sep 2026 08:12:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.140 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789373556; cv=none; b=VADbGYz9f/A17Boqs+tub6Ffw6s7B8o0TWFLyeRzz3uO4yqaUBsvoIGI0eIaX6OI/YCqCKlG7uApwH7+UkVXT0Wjnv2YBJ4JR5dJI6Xy93v4kU1nIXZPxY0qnqcpSW/JQZXI0+a1r3RsQ5YdmBslBafBszQwmFnaYkrSsjCXNIY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789373556; c=relaxed/simple; bh=SxT2adBblINXrJRW2bTxfIq1b2HqI+JoCaLJCsifgDE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=kXkZtm+ArcGI0wTr7Mc2YXdGBirI7FU/s/EGgLnTt0KImWYEdx2c8y13XldsK0R4K4GHgkp4crWgD8s0lZERsPUZPnZp9GDbg6w7MnLgypwFqkqd39DDFBkZTmvR9vXT2GNzDDU9/Y8YqXcK8S1qYay+5yJujSS96C1ICM2WfUM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=QjVBo375; arc=none smtp.client-ip=74.125.225.140 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QjVBo375" Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cfbdac7a1so1042465e9.1 for ; Mon, 14 Sep 2026 01:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789373553; x=1789978353; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=WvL+tll9z+rZiVIgsLmiJriXCowgjHq2TgUmvCdD0FM=; b=QjVBo375JZcFJtecHvZbILRlqVcngQWuPlJ/AqW9LbYoyKePG1QsXSfsQl3se677PY yFwNA9t6Gc19iD9KlVYpYwB6zmwR9fKOMB3UQ8hmXIZQXQZc3RlxAbFRbrG1KAdq4J+L G7T5zFa85QhMyc9aMADvYQtx3CKm28YtPWZ31WZ/DJzEhRALJ9vCD7KWXGYEhcuF4xPz WFlEhJ0vxTTd7V8BOoqoz2UCKOilSGmBIVoNkhlmgpi4ZL0ACMov4iMXW4Zgrrj8XD0m f3euaz59kCIlWHl6LXKH+HvghUs2qIFwu2kz3Ix2Cchm969lj2jGdmW65QQfbVUQGXPu uZ7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789373553; x=1789978353; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=WvL+tll9z+rZiVIgsLmiJriXCowgjHq2TgUmvCdD0FM=; b=nIrWaRCR9GP1hRWvjHPdyk11PIzxsThgSB8oBshtmRYxOTdKZoBZ0xDUjWwJmona17 OykWQf/ltrAWV4qClR94xWBkmhnBpxhK5zZFQpfUCP3MSdMcFfSOROtPBItm2f+1diZ/ mwOo7mTE+0Or/EE0FMkMmIhYszsCFytBWSf9U414QvedOup2A5iMosOm/8sjm8PpE2tW 1uBcXQy4qBqGLJf7UxO1OlbI8Ll/ZYBdFm5AOm/efCReFUyLcepDWM2+yXBEUjw47Tu4 hS1GNiuxjzb1nIsqj0xVJKCskvPIS5Fkbl/XtyhDc109woVB5OaYwO+TD2BjDDHcWprL +WWw== X-Gm-Message-State: AFuF++m0sdIw3hP8P3jslNAu1fCkymcTLmqJBagXgy8uMU3O18n0RpcP XsHlIAN2h/cFcyrhvLorDQ0mZlLud67rAF6SQYhomZARqYm2In1VygoQWTj8UdvQ X-Gm-Gg: AYBFou1TAybzvlzw0mEDAo65BN6V2faFlseb9H07DqLWVwNsWGnfa2NBfSnKanx0mA0 KWtsO3uwxoZrQvYx+eQEjX5t+54T5D2413EYnzfJdsIke3UhxT7ArJVU3yZKENuUQe3sTOJRqyc ViMqxMEPI+9tntOxVWknFnO8jlXuwAIw2a7FrM6ySMKvuLftO0W8bVLbCAwABW6fjtCL3nXqMMh TrMfmlZpFO8W2gH0FIep6bUIoRJkBDb9ccTuHqcNNJ8jDuRTNbtdLGimS7yxhrbvm5K9ekrmGxB HA/4zvFhzcVxJ8ru6t7OE8bOgm/7D7t89PiYeZnldBaJDuvQtb73nLR9w7SVNhg6A1CZlxwJmrB 5HTrrXdHIKiSjM3iEGDH5N25w5kZVMB+/4VuO5SYYA79UhPd0xT5VLTwB1CTrQhrMBeBLaJzur+ RD67jtrVxwoPTuHw/Fi3sVFG3MIq9gOB/KFLSJlpPZurvbxalTvjHFXAm3Y97I1+5LoxxzftRH1 3d8Ll/rdnaDQv6W0go= X-Received: by 2002:a05:600c:4683:b0:49b:9241:7ff0 with SMTP id 5b1f17b1804b1-49e7a5ed9a7mr13611875e9.0.1789373553467; Mon, 14 Sep 2026 01:12:33 -0700 (PDT) Received: from L-P-ITAIH2-L-RF.rf.local ([193.169.70.108]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e60acff8bsm301434385e9.9.2026.09.14.01.12.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Sep 2026 01:12:33 -0700 (PDT) From: Itai Handler To: mwalle@kernel.org, pratyush@kernel.org Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, vigneshr@ti.com, richard@nod.at, miquel.raynal@bootlin.com, takahiro.kuwano@infineon.com, Itai Handler , stable@vger.kernel.org Subject: [PATCH v2 1/3] mtd: spi-nor: fix the lock left held by spi_nor_rww_start_exclusive() Date: Mon, 14 Sep 2026 11:11:47 +0300 Message-Id: <20260914081149.1916589-2-itai.handler@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260914081149.1916589-1-itai.handler@gmail.com> References: <20260914081149.1916589-1-itai.handler@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" spi_nor_rww_start_exclusive() takes nor->lock and never drops it. It returns with the mutex held whether it hands out the exclusive claim or reports the flash busy, leaving the caller holding a lock it does not know it has. Commit 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers") turned its "goto busy" into a plain "return false" and deleted the busy: label that did the mutex_unlock(), but kept the mutex_lock() at the top instead of replacing it with guard(mutex). It is now the only one of the ten spi_nor_rww_{start,end}_* helpers that does not use the guard. Its only caller is spi_nor_prep_and_lock(), so on a flash with SNOR_F_RWW set: - if the flash is idle it returns true with nor->lock held, and the matching spi_nor_unlock_and_unprep() calls spi_nor_rww_end_exclusive(), whose guard(mutex)(&nor->lock) then deadlocks on the non-recursive mutex; - if the flash is busy it returns false with nor->lock held, and wait_event_killable() sleeps holding it, so the operation that would clear ongoing_* can never take the lock to do so. Nothing reaches this today: the only flash with SPI_NOR_RWW is the MX25UW51245G, which has neither OTP nor locking ops, so none of the existing spi_nor_prep_and_lock() callers in otp.c, swp.c and sst.c apply to it. It becomes reachable as soon as any common path takes the exclusive lock. Use guard(mutex) as the other helpers do. Fixes: 03e7bb864d9a ("mtd: spi-nor: use scope-based mutex cleanup helpers") Cc: stable@vger.kernel.org Signed-off-by: Itai Handler --- drivers/mtd/spi-nor/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index ccf4396cdcd0..8bc117b46e02 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -1310,7 +1310,7 @@ static bool spi_nor_rww_start_exclusive(struct spi_no= r *nor) { struct spi_nor_rww *rww =3D &nor->rww; =20 - mutex_lock(&nor->lock); + guard(mutex)(&nor->lock); =20 if (rww->ongoing_io || rww->ongoing_rd || rww->ongoing_pe) return false; --=20 2.34.1 From nobody Fri Sep 25 10:36:35 2026 Received: from mail-wm2-f13.google.com (mail-wm2-f13.google.com [74.125.225.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 520133F8EA2 for ; Mon, 14 Sep 2026 08:12:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789373561; cv=none; b=MWBJP2kfxJs/DwWKORrsFmLpAyTCledGKrEzd8eXeCpcemwIp/DKiZNvhacGgVViHC/a6l1VMDk47SDffl5b1igbGzGeg9a1Q0HzoscxYr9vZyi9iX1TSFyeuCtG/GfW7xWGY5qV2iuJAwngsCOgspX7mwNkOPcdgZtfTR4kzmM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789373561; c=relaxed/simple; bh=QFaOVSaXo24SfPWobdaFHZRuDdTnE2qTXwVifB86x00=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rvzNzzBULFjnDQT2fprsilU1JAVuaUoOBDMfb4uJN1YpsoeRnJU4eDxwcbW+ePbjpzwxLEvGn/bbIeInj8X2lKV5mgvAFfXqksVCq0uZpvSkjftULtoTO1Xya+c7chz6uY8naBC29xfpFoqDkdQX1nzsUMmDIeBwewS4ip1/Azk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jekJlX6t; arc=none smtp.client-ip=74.125.225.141 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jekJlX6t" Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e7c6dbc60so31705e9.3 for ; Mon, 14 Sep 2026 01:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789373557; x=1789978357; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Aj7IiomPonUj9qywT6/YurZdwlPYR2aG7U6PbbSw37I=; b=jekJlX6tBY33oG2iw2w/02lsBFrVP5pjNjIEaaZ0k7x5tPqSacnT8UnyuD/xLZH8H/ r3pG+DgiBtKzgsVgVIX/PxcjFOT9AU3jG5C1z9krtacehnIgGWYJC2MHqRBafy2WES6j /csH5PyKvUo2ZjqJ1UUVT93vmGvYdlGOUvTtr+vWrkA6Kd2zJVEJg3OogoUeHyito6Rr QsNXmmwqR3J7KOYRm668h6sxSoJMeNSDOTrC9c+KM0+Szl/KuX0cA2o5JVESNgElFQ4I eYV6VjKgQ5RCFBJRBwPieCrGJHuTT15RWavYUjPR5AjYXxQmFLzxNqXmAh58FlVTVJJa yFJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789373557; x=1789978357; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Aj7IiomPonUj9qywT6/YurZdwlPYR2aG7U6PbbSw37I=; b=CEnRUt6uASIm3fVK0ipFFBufblwMf9MudhFGpqL/7Vf5EgF+fUDEu7zKYWKtZhs4Lu 5p7oChSxedAP8JcvZDpnt0ysGJj9O7xcpvKJRv61QsmJnBBUyNshuSj9T0Wah1tnDjDC bQLL9VQX80WWm+0GqIgD9wkL2jz5k0YmqcrvdLdIySpRH8ylSFz37tF0jGoCCZrYBC05 Mq1hkpbXtQ1OBPyK2dtqTCVvGv5f42VIc5LTUhOjB0gj03jkVM2ZX9jqGaaWRMJNXKy7 xFdKIhlD/HgNzfo5Vw4Wj/zgIeD+vRmIl/7apbZtE/OvTQd1o10EmqHfsTjVmIrkFCUZ hk2A== X-Gm-Message-State: AFuF++ndDfawQmaOPYM5k8Jr+xcxnwRgF4i8cbrg4Cc6/R+7pp0vq0mb DVwHJVHcjgJF69M948utlTPQja6w853bfGcKaKcNttnWkLgRZZIY8OYA X-Gm-Gg: AYBFou13UIYBem5ONxsVLLlrTf1EajNj5JMj8WNPNdtcU/ZwGWgMvf/f/R5Rdlj8tVf FBdGyXCcbmM0omFL1tAphmKS3aMvFalHoQFGbw6wyTHhf27VD8mPp4GRmUx8wywJF1cRpTt2WIZ w2XjqajaecwQQxJUVDCWMbUI8T3DsyEB7Yn48TNiart/uhou27G6ZwazAMBSrIbgjRqjUUGBcnZ CCVITZIpl+qdniaN6wIFh6karIQbdw5Vj9kS2JVtClqZwVynLS9zFFiKLiCSPClKtBGEGOPoGR9 jtf5Nc6zr4cc1MAfqx8ouAAJLFxjXh1R78zCKIQTV+RagWyh5O0nx6601h+77W4qLNkIzFO3Mxa YYeIlSIVMsCaU4QoCJ9WrrObzCxpluesFul6g9flGmVENGhC2acMjI4eYZUHeRjbZWrhlufDLdj Zw2mVommWNogxtO3/K90hrqbZwC8TWGcNOQOu0n+zZLrl7W7eUMbZLvscj4Pq63cnU7P687v1An xSgwR1DYxf+59MjFp8= X-Received: by 2002:a05:600c:3b9f:b0:49e:745d:5768 with SMTP id 5b1f17b1804b1-49e7a5f1f60mr19047885e9.0.1789373557305; Mon, 14 Sep 2026 01:12:37 -0700 (PDT) Received: from L-P-ITAIH2-L-RF.rf.local ([193.169.70.108]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e60acff8bsm301434385e9.9.2026.09.14.01.12.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Sep 2026 01:12:36 -0700 (PDT) From: Itai Handler To: mwalle@kernel.org, pratyush@kernel.org Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, vigneshr@ti.com, richard@nod.at, miquel.raynal@bootlin.com, takahiro.kuwano@infineon.com, Itai Handler , stable@vger.kernel.org Subject: [PATCH v2 2/3] mtd: spi-nor: take the flash lock in spi_nor_shutdown() Date: Mon, 14 Sep 2026 11:11:48 +0300 Message-Id: <20260914081149.1916589-3-itai.handler@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260914081149.1916589-1-itai.handler@gmail.com> References: <20260914081149.1916589-1-itai.handler@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" spi_nor_shutdown() calls spi_nor_restore() to put the flash back into 3-byte addressing before the system reboots or kexecs. It does so without taking nor->lock, which every other path that talks to the chip acquires through spi_nor_prep_and_lock(). device_shutdown() does not freeze userspace and does not stop kernel threads; it walks the device list calling ->shutdown with all CPUs online. Another thread can therefore be in the middle of an operation, with the restore running concurrently with it. A write and a read are both damaged, in different ways. A program or erase leaves the flash busy, and a busy flash accepts only status register reads and ignores everything else, including the EX4B that spi_nor_restore() sends. Neither spi_nor_write_enable() nor spi_nor_set_4byte_addr_mode() reads anything back, so the restore reports success while the flash is left in 4-byte addressing. The next boot stage then addresses it with 3 bytes and reads the wrong data, which is the failure commit 59b356ffd0b0 ("mtd: m25p80: restore the status of SPI flash when exiting") introduced this restore to prevent. A read, by contrast, does not ignore the restore - it is corrupted by it. spi_nor_read() holds the lock across a loop that issues one spi_nor_read_data() per chunk, each using nor->addr_nbytes. spi_nor_set_4byte_addr_mode() updates nor->params->addr_nbytes and not nor->addr_nbytes, so a restore landing between two chunks switches the chip to 3-byte addressing while the driver carries on sending 4 address bytes. The rest of the transfer is addressed wrongly and returns wrong data, and nothing reports an error. A restore may also soft reset the chip in the middle of that same read. Take nor->lock for the restore, so it runs between operations instead of during one: a program or erase has finished waiting on the chip, and a read has issued its last chunk. This is a locking fix rather than a missing wait - each operation already waits for completion at the site that started it. This narrows the race without closing it. The restore still runs while MTD users are attached, so an operation that starts after it has completed will address a chip that is now in 3-byte mode while nor->addr_nbytes is still 4. Closing that as well would mean having MTD stop accepting operations before ->shutdown runs, which is a larger change; serialising against the operations already in flight is what keeps the restore itself from being issued into a busy chip. Fixes: 59b356ffd0b0 ("mtd: m25p80: restore the status of SPI flash when exi= ting") Cc: stable@vger.kernel.org Signed-off-by: Itai Handler --- drivers/mtd/spi-nor/core.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 8bc117b46e02..647bf8dce719 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -3862,8 +3862,21 @@ static int spi_nor_remove(struct spi_mem *spimem) static void spi_nor_shutdown(struct spi_mem *spimem) { struct spi_nor *nor =3D spi_mem_get_drvdata(spimem); + int ret; + + /* + * Wait for an operation started by another thread to finish. + * device_shutdown() runs with MTD users still active: a busy flash + * ignores the commands spi_nor_restore() issues, leaving it in + * 4-byte address mode, and a restore landing mid-read changes the + * chip's address width under the transfer. + */ + ret =3D spi_nor_prep_and_lock(nor); + if (ret) + return; =20 spi_nor_restore(nor); + spi_nor_unlock_and_unprep(nor); } =20 /* --=20 2.34.1 From nobody Fri Sep 25 10:36:35 2026 Received: from mail-wr2-f12.google.com (mail-wr2-f12.google.com [74.125.225.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B03A93FC5A1 for ; Mon, 14 Sep 2026 08:12:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.76 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789373565; cv=none; b=b25UdqF1JqKgPGrO3PJrJbugJVgB9sVF/kfGj/ukr9fPpuDcnUYJLYAIunhOr0q3rL9GsmltGqoRHCQ4iPHVqVcbNMCqgQD8f8c6roGI30xfv+wf5w0nUnKyn04utLNYS0knuAtVOp+dnY8mkOft9FocnIr/s/gGLFifUs3uwUk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789373565; c=relaxed/simple; bh=EDHSCA+pQrWnWiVBfpdnQocplt0oUa4z84IRuUiPecM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=j8j22cxV4nxwV4OZTpJE8FiCtBDwvjzRiX/YJEikC+2oged8o3r7f3O7iN4heZgPrcdwJGDlS848NnhgDtskpyz7KIB9U0NzMVanrEvOjle73+ndOZmCDOWuRmzePNssWwAGrmNisn/5fSAPGsGxoH7tICjNheuWbK5UHv68Ou0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=G8XGCB0l; arc=none smtp.client-ip=74.125.225.76 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="G8XGCB0l" Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482e1b429f7so172571f8f.2 for ; Mon, 14 Sep 2026 01:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789373561; x=1789978361; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=dfBKtg2pSNUBsI4+N4eKUAVwi5zQ46GSi86GxU4/gUs=; b=G8XGCB0lpoKExbvdMezD5n8eTD1iVUz8w6u/LcItLNzMYj23dj8Q2JhznBlDnSE97/ 62Kd364oD+4siUStJ4ZR+PtOIfcyCc5Hq4tQRE41772B+aioeYrhaXcHJLt/wH79LdYP I7ExstsUAFOVYj/OatTRBbMwUzdgb9td+fsYcH42T6iXBzR0dybjTAyLqRi7sv/QcfcH /v/a1CyDmLlVdGl7Hcoto1caaJj41tpgLvpnxHWW3rZe/2rOGjd5fw+UI9ruIlnJfUSs MZhpsdMzt3RubvbZ5kNqh1mQ7clBcIzb8AhiU9cmAwhnTIEjtIsNePu325+LzkgpavdA zgTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789373561; x=1789978361; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=dfBKtg2pSNUBsI4+N4eKUAVwi5zQ46GSi86GxU4/gUs=; b=eOOnE2DjTh/w1P1PHkipXS23ryiSjZ6J+Upw+eDvBkNEd3MsvUrM6Vn4n2f9jp3NA+ sKr8Ds9IH01JW3+LCaOVNshzj4a1LvEnAiuTWYk7/L8t6ejM7pi7f3dweqEDzCyUzyjH 3jrFDlQQ3zvExjHq5IhNZBrQS5azF9Zgc2l0bHcwymBCxspy6dKQ72BpzaqiNU+7DJRc JShx4H1onVkNFPGxw3rSeWDYPLlNImnc/XwTLMfVjcNDenq9bxEUpz5sWW4rJ2nXKXpJ +hQe9Mb74P54dTPTZBiVeTESL3lKgSa4ULI2DOHzBBXRBVktHdic+CQj8ToxDZAo41ic ODjQ== X-Gm-Message-State: AFuF++kGHl6WhY+b/5ChguO4HxqaR9Xtc640p4LblBjmnTyhASo2v9FU OePj68057Mi4ijer6sj9uetccPdmZStebjBSHxZ5KDn8ofNuqgQO7bCj X-Gm-Gg: AYBFou3/kl/WMRH0waYjiTmMPkLfYyvzbi7903ccB+4Lqp7dz3ILuFJvfjlRwqgYlHw IKWMfJ4qt1AZdvLVcX1GWv5+fMR6wYGoFmVCHpdj8WpppuuM5/Cou6AlGGJztZOC5K1Xc7MJUXD k/2AM7lp2qO/sqRqhux6oBt2GXZHjmZianx6Z+cqwtlXTboWd6ngWp2GujSAzXLHE/Uy0I+xcor KJbfFACCETSuKXKl4bAEdM/NzVLRVmIC107rb67vvcKDzgRenqLRBg5G/SJ63mtZfbN/r6trKlY aNIaUPLjApRh5yeI309ymLWJJAax5f2d+gxmtNaueClDnqQrO1ounUTp5gY1okYaQUl88miJxMz r/j7Km4n+5whQ8EAXP/vvZZE8PvzFAP3du0fUC926I2waeyNbesJz/uD8ToZ2S7C48b0vtsoeBD 7kVC2xssQuzCB/29NsthC3GUtE5Cis2Kk0rqmCyX1lAYtEEt/HRdMuQJbcebzdyXAdZ5HaiFHiD DGMxHsYPd6B4wZ4Bpk= X-Received: by 2002:a05:600c:3ba4:b0:49e:6806:5712 with SMTP id 5b1f17b1804b1-49e7a66d0f5mr18491365e9.2.1789373561412; Mon, 14 Sep 2026 01:12:41 -0700 (PDT) Received: from L-P-ITAIH2-L-RF.rf.local ([193.169.70.108]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e60acff8bsm301434385e9.9.2026.09.14.01.12.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Sep 2026 01:12:41 -0700 (PDT) From: Itai Handler To: mwalle@kernel.org, pratyush@kernel.org Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, vigneshr@ti.com, richard@nod.at, miquel.raynal@bootlin.com, takahiro.kuwano@infineon.com, Itai Handler Subject: [PATCH v2 3/3] mtd: spi-nor: take the flash lock in spi_nor_remove() Date: Mon, 14 Sep 2026 11:11:49 +0300 Message-Id: <20260914081149.1916589-4-itai.handler@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260914081149.1916589-1-itai.handler@gmail.com> References: <20260914081149.1916589-1-itai.handler@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" spi_nor_remove() restores the addressing mode with the same unlocked call to spi_nor_restore() that spi_nor_shutdown() used before the previous patch, and it is exposed the same way: the MTD device is still registered at that point, so an unbind can run the restore while another thread is in the middle of an operation. A busy flash silently ignores the restore, and a restore that lands between two chunks of a read switches the chip to 3-byte addressing while the driver keeps sending 4 address bytes. Moving the restore after mtd_device_unregister() would not fix this. Since commit 19bfa9ebebb5 ("mtd: use refcount to prevent corruption") del_mtd_device() drops a reference instead of refusing with -EBUSY when the device is in use, so unregistering returns right away and does not wait for an operation that is already running. Take nor->lock for the restore, as spi_nor_shutdown() now does. The unregister stays unconditional, so a flash whose restore had to be skipped is still torn down. Fixes: 59b356ffd0b0 ("mtd: m25p80: restore the status of SPI flash when exi= ting") Signed-off-by: Itai Handler --- drivers/mtd/spi-nor/core.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 647bf8dce719..8d0302565445 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -3852,8 +3852,14 @@ static int spi_nor_probe(struct spi_mem *spimem) static int spi_nor_remove(struct spi_mem *spimem) { struct spi_nor *nor =3D spi_mem_get_drvdata(spimem); + int ret; =20 - spi_nor_restore(nor); + /* As in spi_nor_shutdown(), do not restore under an operation. */ + ret =3D spi_nor_prep_and_lock(nor); + if (!ret) { + spi_nor_restore(nor); + spi_nor_unlock_and_unprep(nor); + } =20 /* Clean up MTD stuff. */ return mtd_device_unregister(&nor->mtd); --=20 2.34.1