Re: [PATCH v3 3/7] mtd: spi-nor: Add support for panic writes - sashiko-bot

From: sashiko-bot@kernel.org
To: "Paul Cercueil" <paul.cercueil@bootlin.com>,
	"Pratyush Yadav" <pratyush@kernel.org>,
	"Michael Walle" <mwalle@kernel.org>,
	"Takahiro Kuwano" <takahiro.kuwano@infineon.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Cc: "Kees Cook" <kees@kernel.org>, "Tony Luck" <tony.luck@intel.com>,
	"Guilherme G . Piccoli" <gpiccoli@igalia.com>,
	linux-mtd@lists.infradead.org,
	"Bharat Bhushan" <bbhushan2@marvell.com>,
	"Sunil Kovvuri Goutham" <sgoutham@marvell.com>,
	"Tanmay Jagdale" <tanmay@marvell.com>
Subject: Re: [PATCH v3 3/7] mtd: spi-nor: Add support for panic writes
Date: Wed, 14 Oct 2026 15:57:32 +0000	[thread overview]
Message-ID: <sashiko-outbox-171505@kernel.org> (raw)
In-Reply-To: <20261014154301.157755-4-paul.cercueil@bootlin.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mtd: spi-nor: kmalloc/kfree during panic write causes deadlock
--

commit 3bd35bd5922a50a6d084d4da3c21aebcee2351cd
Author: Tanmay Jagdale <tanmay@marvell.com>

mtd: spi-nor: Add support for panic writes

This commit introduces the functionality for SPI NOR controllers to perform
panic writes. It attempts to bypass locked mutexes and sleep operations
when doing a panic write, since preemption and IRQs are disabled.

> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 58257cc21c681..d5e572287bb73 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
[ ... ]
> @@ -2203,7 +2242,8 @@ static int spi_nor_octal_dtr_write(struct spi_nor *nor, loff_t to, size_t len,
>  	if (IS_ALIGNED(to, 2) && IS_ALIGNED(len, 2))
>  		return spi_nor_write_data(nor, to, len, buf);
>  
> -	tmp_buf = kmalloc(nor->params->page_size, GFP_KERNEL);
> +	tmp_buf = kmalloc(nor->params->page_size,
> +			  nor->mtd.oops_panic_write ? GFP_ATOMIC : GFP_KERNEL);

[Severity: High]
Can this kmalloc() call in spi_nor_octal_dtr_write(), and the subsequent
kfree(), cause a deadlock during a panic?

While GFP_ATOMIC prevents the scheduler from sleeping or reclaiming memory,
the SLUB/SLAB memory allocator still fundamentally relies on raw spinlocks
(e.g., kmem_cache_node->list_lock or pcp->lock) for its freelists.

Since spi_nor_panic_write() is invoked in a panic context where local
interrupts are disabled and all other CPUs have been forcibly halted, if
any halted CPU happened to be holding a slab lock at the moment of the
crash, the panicking CPU will spin indefinitely waiting for it.

Should this panic path rely on a pre-allocated buffer (such as
nor->bouncebuf) instead to guarantee the panic dump can be written?

>  	if (!tmp_buf)
>  		return -ENOMEM;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014154301.157755-1-paul.cercueil@bootlin.com?part=3

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/