Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Date:   Mon, 25 Sep 2023 11:14:40 +0200 (CEST)
From:   Richard Weinberger <richard@nod.at>
To:     ZhaoLong Wang <wangzhaolong1@huawei.com>
Cc:     Vignesh Raghavendra <vigneshr@ti.com>,
        linux-mtd <linux-mtd@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        chengzhihao1 <chengzhihao1@huawei.com>,
        yi zhang <yi.zhang@huawei.com>, yangerkun@huawei.com,
        Miquel Raynal <miquel.raynal@bootlin.com>
Message-ID: <495954216.80155.1695633280285.JavaMail.zimbra@nod.at>
In-Reply-To: <20230925104938.3f7b4284@xps-13>
References: <20230923005856.2538223-1-wangzhaolong1@huawei.com> <20230925104938.3f7b4284@xps-13>
Subject: Re: [RFC] mtd: Fix error code loss in mtdchar_read() function.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Thread-Topic: Fix error code loss in mtdchar_read() function.
Thread-Index: TtuXiU41OYpt7ia3mZdS86/izvLuwg==
Precedence: bulk

----- Ursprüngliche Mail -----
>> 'total_retlen' is 0, not the error code.
> 
> Actually after looking at the code, I have no strong opinion
> regarding whether we should return 0 or an error code in this case.
> 
> 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:
> 
>                /* Nand returns -EBADMSG on ECC errors, but it returns
>                 * the data. For our userspace tools it is important
>                 * to dump areas with ECC errors!
>                 * For kernel internal usage it also might return -EUCLEAN
>                 * to signal the caller that a bitflip has occurred and has
>                 * been corrected by the ECC algorithm.
>                 * Userspace software which accesses NAND this way
>                 * must be aware of the fact that it deals with NAND
>                 */
> 
>> This problem causes the user-space program to encounter EOF when it has
>> not finished reading the mtd partion, and this also violates the read
>> system call standard in POSIX.

This is a special purpose device file and not a regular file.
Please explain in detail why this violates POSIX and which program breaks.

As pointed out by Miquel, the comment makes it clean that this behavior is
on purpose. If we return now all of a sudden -EBADMSG for the described
scenario we might even break existing MTD userspace.

Thanks,
//richard