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>
Subject: Re: [RFC] mtd: Fix error code loss in mtdchar_read() function.
Date: Mon, 25 Sep 2023 11:14:40 +0200 (CEST) [thread overview]
Message-ID: <495954216.80155.1695633280285.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20230925104938.3f7b4284@xps-13>
----- 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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2023-09-25 9:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-23 0:58 [RFC] mtd: Fix error code loss in mtdchar_read() function ZhaoLong Wang
2023-09-25 8:49 ` Miquel Raynal
2023-09-25 9:14 ` Richard Weinberger [this message]
2023-09-25 9:28 ` Miquel Raynal
2023-09-25 9:31 ` Richard Weinberger
2023-09-25 14:22 ` ZhaoLong Wang
2023-09-25 14:03 ` Richard Weinberger
2023-09-25 14:37 ` Miquel Raynal
2023-09-25 14:59 ` Richard Weinberger
2023-09-25 15:06 ` Miquel Raynal
2023-09-26 1:08 ` ZhaoLong Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=495954216.80155.1695633280285.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=chengzhihao1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=vigneshr@ti.com \
--cc=wangzhaolong1@huawei.com \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox