[PATCH v2 3/7] mtd: spi-nor: Add support for panic writes

[Paul Cercueil]

Hi Sashiko,

Le mardi 13 octobre 2026 à 14:27 +0000, sashiko-bot at kernel.org a écrit :
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s)
> to consider:
> - [Critical] pm: spi-mem: mishandled pm_runtime_get_if_active() silently
> breaks panic write
> - [High] mm: spi-nor: panic write allocation uses sleeping GFP mask
> - [High] spi: spi-mem: panic write fallback path sleeps on ENOTSUPP
> --
> 
> commit a1f9f053470ff10fa10c133dc5aeb0827bc367a1
> Author: Tanmay Jagdale <tanmay at marvell.com>
> 
>     mtd: spi-nor: Add support for panic writes
>     
>     If the SPI controller supports it, provide the functionality of doing a
>     panic write.
>     
>     Update the spi-nor core code and controllers to make sure they won't try
>     to grab locked mutexes or sleep when doing a panic write, as preemption
>     and IRQs are disabled.
> 
> > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > index 2509fb983d4f2..281acc54b3245 100644
> > --- a/drivers/mtd/spi-nor/core.c
> > +++ b/drivers/mtd/spi-nor/core.c
> 
> [ ... ]
> 
> > @@ -2196,6 +2235,7 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t
> > from, size_t len,
> >  static int spi_nor_octal_dtr_write(struct spi_nor *nor, loff_t to, size_t
> > len,
> >  				   const u8 *buf)
> >  {
> > +	gfp_t mm_flags = GFP_KERNEL;
> >  	u8 *tmp_buf;
> >  	size_t bytes_written;
> >  	loff_t start, end;
> > @@ -2204,7 +2244,10 @@ 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);
> > +	if (nor->mtd.oops_panic_write)
> > +		mm_flags |= GFP_ATOMIC;
> > +
> > +	tmp_buf = kmalloc(nor->params->page_size, mm_flags);
> 
> [Severity: High]
> Does this bitwise OR successfully remove the sleepable __GFP_DIRECT_RECLAIM
> flag?
> 
> Because mm_flags is initialized to GFP_KERNEL (which includes
> __GFP_DIRECT_RECLAIM), bitwise ORing GFP_ATOMIC into the mask does not
> clear the __GFP_DIRECT_RECLAIM bit. This means the resulting mask still
> instructs the page allocator that it is allowed to sleep and enter direct
> reclaim.

My bad, it should be GFP_KERNEL *or* GFP_ATOMIC. Good catch.

Cheers,
-Paul