linux-kernel - Re: [PATCH] nand: raw: use write_oob_raw for MTD_OPS_AUTO

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200504123237.5c128668@collabora.com>
Date:   Mon, 4 May 2020 12:32:37 +0200
From:   Boris Brezillon <boris.brezillon@...labora.com>
To:     Álvaro Fernández Rojas <noltari@...il.com>
Cc:     miquel.raynal@...tlin.com, richard@....at, vigneshr@...com,
        s.hauer@...gutronix.de, masonccyang@...c.com.tw,
        christophe.kerello@...com, stefan@...er.ch, piotrs@...ence.com,
        devik@...labs.cz, tglx@...utronix.de,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nand: raw: use write_oob_raw for MTD_OPS_AUTO_OOB mode

On Mon,  4 May 2020 11:42:53 +0200
Álvaro Fernández Rojas <noltari@...il.com> wrote:

> Some NAND controllers change the ECC bytes when OOB is written with ECC
> enabled.
> This is a problem in brcmnand, since adding JFFS2 cleanmarkers after the page
> has been erased will change the ECC bytes to 0 and the controller will think
> the block is bad.
> It can be fixed by using write_oob_raw, which ensures ECC is disabled.
> 
> Signed-off-by: Álvaro Fernández Rojas <noltari@...il.com>
> ---
>  drivers/mtd/nand/raw/nand_base.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index c24e5e2ba130..755d25200520 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -488,7 +488,7 @@ static int nand_do_write_oob(struct nand_chip *chip, loff_t to,
>  
>  	nand_fill_oob(chip, ops->oobbuf, ops->ooblen, ops);
>  
> -	if (ops->mode == MTD_OPS_RAW)
> +	if (ops->mode == MTD_OPS_AUTO_OOB || ops->mode == MTD_OPS_RAW)
>  		status = chip->ecc.write_oob_raw(chip, page & chip->pagemask);

The doc says:

@MTD_OPS_PLACE_OOB:  OOB data are placed at the given offset (default)
@MTD_OPS_AUTO_OOB:   OOB data are automatically placed at the free areas
                     which are defined by the internal ecclayout
@MTD_OPS_RAW:        data are transferred as-is, with no error
		     correction; this mode implies %MTD_OPS_PLACE_OOB

To me, that means MTD_OPS_PLACE_OOB and MTD_OPS_AUTO_OOB do not imply
MTD_OPS_RAW. Anyway those modes are just too vague. We really should
separate the ECC-disabled/ECC-enabled concept (AKA raw vs non-raw mode)
from the OOB placement scheme. IIRC, Miquel had a patchset doing that.

We also should have the concept of protected OOB-region vs
unprotected-OOB-region if we want JFFS2 to work with controllers that
protect part of the OOB region. Once we have that we can patch JFFS2
to write things with "ECC-disabled"+"auto-OOB-placement-on-unprotected
area".

>  	else
>  		status = chip->ecc.write_oob(chip, page & chip->pagemask);