linux-kernel - Re: [PATCH v2] mtd: spi-nor: Check for zero erase size in spi_nor_find_best_erase

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0cabce03-bc22-eb3d-fa77-a1f5f787784d@microchip.com>
Date:   Sat, 18 Dec 2021 01:31:17 +0000
From:   <Tudor.Ambarus@...rochip.com>
To:     <alexander.sverdlin@...ia.com>, <linux-mtd@...ts.infradead.org>
CC:     <p.yadav@...com>, <michael@...le.cc>, <miquel.raynal@...tlin.com>,
        <richard@....at>, <vigneshr@...com>,
        <linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>
Subject: Re: [PATCH v2] mtd: spi-nor: Check for zero erase size in
 spi_nor_find_best_erase_type()

On 11/19/21 10:14 AM, Alexander A Sverdlin wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> From: Alexander Sverdlin <alexander.sverdlin@...ia.com>

Hi, nice to hear from you again!

> 
> Erase can be zeroed in spi_nor_parse_4bait() or
> spi_nor_init_non_uniform_erase_map(). In practice it happened with
> mt25qu256a, which supports 4K, 32K, 64K erases with 3b address commands,
> but only 4K and 64K erase with 4b address commands.

:D

> 
> Fixes: dc92843159a7 ("mtd: spi-nor: fix erase_type array to indicate current map conf")
> Cc: stable@...r.kernel.org
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@...ia.com>
> ---
> Changes in v2:
> erase->opcode -> erase->size
> 
>  drivers/mtd/spi-nor/core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 88dd090..183ea9d 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1400,6 +1400,8 @@ spi_nor_find_best_erase_type(const struct spi_nor_erase_map *map,
>                         continue;
> 
>                 erase = &map->erase_type[i];
> +               if (!erase->size)
> +                       continue;

I need a bit of context here. Does mt25qu256a has a uniform erase layout?
i.e. Does your flash has sectors of more than one size or does not allow
the 4K and 64K erase types to be applied on all sectors in the 4B case?
If no, you should have been in the spi_nor_has_uniform_erase() case, and
if this case does not suit you, maybe we should update the code for this
specific case instead.

On a short look I see that this flash defines just BFPT and 4BAIT table,
so no SMPT. It looks like you're forcing the flash to behave as it had defined
SMPT. Am I wrong?

Also, should we update the region's erase mask instead and mask out the
unsupported erase type? I would love to hear more about your use case.

Cheers,
ta