linux-kernel - Re: [PATCH 1/3] ARM: configs: at91: Remove MTD_BLOCK and use MTD_UBI

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] [day] [month] [year] [list]

Date:   Thu, 5 May 2022 15:49:47 +0200
From:   Nicolas Ferre <nicolas.ferre@...rochip.com>
To:     Tudor Ambarus <tudor.ambarus@...rochip.com>,
        <claudiu.beznea@...rochip.com>, <alexandre.belloni@...tlin.com>
CC:     <codrin.ciubotariu@...rochip.com>, <eugen.hristev@...rochip.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] ARM: configs: at91: Remove MTD_BLOCK and use
 MTD_UBI_BLOCK for read only block FS

On 20/04/2022 at 15:47, Tudor Ambarus wrote:
> Using mtdblock on raw flashes is generally a bad idea as it lacks
> wear-leveling, bad block handling or power-cut management.
> What happens when you use mtdblock and you change any sector of your
> mtdblockX device, is that it reads the whole corresponding eraseblock into
> the memory, erases the eraseblock, changes the sector in RAM, and writes
> the whole eraseblock back. If you have a power failure when the eraseblock
> is being erased, you lose all the block device sectors in it. The flash
> will likely decay soon because the eraseblocks will wear out.
> 
> Remove this archaic tool as its use case should rather be only for debug
> purposes. This means that write-capable block file systems like ext2,
> ext3, FAT, etc. will no longer be addressed with at91 defconfigs. For
> read only block filesystems like SquashFS, use MTD_UBI_BLOCK instead and
> benefit of UBI's bit-flip handling and wear-levelling.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus@...rochip.com>

For the whole series:
Acked-by: Nicolas Ferre <nicolas.ferre@...rochip.com>

and queued in at91-defconfig for 5.19.

Best regards,
   Nicolas

> ---
>   arch/arm/configs/at91_dt_defconfig | 2 +-
>   arch/arm/configs/sama5_defconfig   | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig
> index 549d01be0b47..cf79510631ea 100644
> --- a/arch/arm/configs/at91_dt_defconfig
> +++ b/arch/arm/configs/at91_dt_defconfig
> @@ -50,13 +50,13 @@ CONFIG_DEVTMPFS_MOUNT=y
>   CONFIG_MTD=y
>   CONFIG_MTD_TESTS=m
>   CONFIG_MTD_CMDLINE_PARTS=y
> -CONFIG_MTD_BLOCK=y
>   CONFIG_MTD_DATAFLASH=y
>   CONFIG_MTD_RAW_NAND=y
>   CONFIG_MTD_NAND_ATMEL=y
>   CONFIG_MTD_SPI_NOR=y
>   CONFIG_MTD_UBI=y
>   CONFIG_MTD_UBI_FASTMAP=y
> +CONFIG_MTD_UBI_BLOCK=y
>   CONFIG_BLK_DEV_LOOP=y
>   CONFIG_BLK_DEV_RAM=y
>   CONFIG_BLK_DEV_RAM_COUNT=4
> diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
> index 03dd80c2a19e..1c4c5a035518 100644
> --- a/arch/arm/configs/sama5_defconfig
> +++ b/arch/arm/configs/sama5_defconfig
> @@ -57,13 +57,13 @@ CONFIG_DEVTMPFS_MOUNT=y
>   CONFIG_MTD=y
>   CONFIG_MTD_TESTS=m
>   CONFIG_MTD_CMDLINE_PARTS=y
> -CONFIG_MTD_BLOCK=y
>   CONFIG_MTD_CFI=y
>   CONFIG_MTD_RAW_NAND=y
>   CONFIG_MTD_NAND_ATMEL=y
>   CONFIG_MTD_SPI_NOR=y
>   CONFIG_MTD_UBI=y
>   CONFIG_MTD_UBI_FASTMAP=y
> +CONFIG_MTD_UBI_BLOCK=y
>   CONFIG_BLK_DEV_LOOP=y
>   CONFIG_BLK_DEV_RAM=y
>   CONFIG_BLK_DEV_RAM_COUNT=4


-- 
Nicolas Ferre