linux-kernel - Re: [PATCH] mtd: spi-nor: write support for minor aligned partitions

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]

Date:   Thu, 10 Jun 2021 15:38:01 +0530
From:   Pratyush Yadav <p.yadav@...com>
To:     John Thomson <git@...nthomson.fastmail.com.au>
CC:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Michael Walle <michael@...le.cc>,
        <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        kernel test robot <lkp@...el.com>,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: [PATCH] mtd: spi-nor: write support for minor aligned partitions

On 08/06/21 02:07PM, John Thomson wrote:
> Do not prevent writing to mtd partitions where a partition boundary sits
> on a minor erasesize boundary.
> This addresses a FIXME that has been present since the start of the
> linux git history:
> /* Doesn't start on a boundary of major erase size */
> /* FIXME: Let it be writable if it is on a boundary of
>  * _minor_ erase size though */
> 
> Allow a uniform erase region spi-nor device to be configured
> to use the non-uniform erase regions code path for an erase with:
> CONFIG_MTD_SPI_NOR_USE_VARIABLE_ERASE=y
> 
> On supporting hardware (SECT_4K: majority of current SPI-NOR device)
> provide the facility for an erase to use the least number
> of SPI-NOR operations, as well as access to 4K erase without
> requiring CONFIG_MTD_SPI_NOR_USE_4K_SECTORS
> 
> Introduce erasesize_minor to the mtd struct,
> the smallest erasesize supported by the device

Instead of having just a major and minor erase size, wouldn't it make 
more sense to have a list of all supported erases on a sector? That is, 
instead of hard coding two erase size instead of one, how about 
generalizing the erase machinery to allow any number of erase sizes on a 
sector and then choosing the most efficient one on run time?

For example, imagine a device can support 4K, 64K, and 256K erases on 
each sector. Then you should be able to use 2 x 4K erases if you want to 
erase 8K, 2 x 64K + 1 x 4K erases for 132K and so on.

I am not very familiar with MTD erase machinery so I would like someone 
else to chime in, but I think my suggestion above is the better way 
forward.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.