linux-kernel - Re: [RFC] mtd: Fix error code loss in mtdchar

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:   Mon, 25 Sep 2023 22:22:12 +0800
From:   ZhaoLong Wang <wangzhaolong1@...wei.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
CC:     <richard@....at>, <vigneshr@...com>,
        <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <chengzhihao1@...wei.com>, <yi.zhang@...wei.com>,
        <yangerkun@...wei.com>
Subject: Re: [RFC] mtd: Fix error code loss in mtdchar_read() function.

> There is this comment right above, and I'm not sure it is still up to
> date because I believe many drivers just don't provide the data upon
> ECC error:

After observing the nand_base framework code, I think the current nand_base
framework can limit the length of retlen to 0 when an ECC error occurs. The
prerequisite is that the NAND driver development personnel can correctly 
provide
the return value of the function according to the requirements of the 
chip->ecc.read_page()
callback.

However, the read_page() callback comment does not notice the 
particularity of the
following two error codes:

* -EUCLEAN - Returned by the MTD layer when maxbitflips greater then 
bitflip_threshold
* -EBADMSG - Returned by NAND Generic Layer when the statistical ECC 
error stats
                          changes and the number of retries is exhausted.

These two error codes are handled by the upper layer and should not be 
returned by the
NAND driver developer. But some driver developers don't realize this.

So I don't think it's worth fixing right now, but is the description of 
the return value of the
callback too simplistic? Is there any other more detailed description 
document for reference?