From: Miquel Raynal <miquel.raynal@bootlin.com>
To: ZhaoLong Wang <wangzhaolong1@huawei.com>
Cc: <richard@nod.at>, <vigneshr@ti.com>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
<chengzhihao1@huawei.com>, <yi.zhang@huawei.com>,
<yangerkun@huawei.com>
Subject: Re: [RFC] mtd: Fix error code loss in mtdchar_read() function.
Date: Mon, 25 Sep 2023 10:49:38 +0200 [thread overview]
Message-ID: <20230925104938.3f7b4284@xps-13> (raw)
In-Reply-To: <20230923005856.2538223-1-wangzhaolong1@huawei.com>
Hello,
Richard, your advice is welcome here.
wangzhaolong1@huawei.com wrote on Sat, 23 Sep 2023 08:58:56 +0800:
> In the first while loop, if the mtd_read() function returns -EBADMSG
s/the// s/function//
,
> and 'retlen' returns 0, the loop break and the function returns value
s/and// remains to 0. The loop breaks and the function
returns 'total_retlen' which is 0 instead of the error code.
> '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.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217939
> Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
> ---
> drivers/mtd/mtdchar.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 8dc4f5c493fc..ba60dc6bef98 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -211,7 +211,7 @@ static ssize_t mtdchar_read(struct file *file, char __user *buf, size_t count,
> }
>
> kfree(kbuf);
> - return total_retlen;
> + return total_retlen ? total_retlen : ret;
This is kind of wrong, if ret is 0 then you return ret while you should
return total_retlen. In practice it does not really matter, the result
is the same, but it makes it harder to understand the code IMHO.
> } /* mtdchar_read */
>
> static ssize_t mtdchar_write(struct file *file, const char __user *buf, size_t count,
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: ZhaoLong Wang <wangzhaolong1@huawei.com>
Cc: <richard@nod.at>, <vigneshr@ti.com>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
<chengzhihao1@huawei.com>, <yi.zhang@huawei.com>,
<yangerkun@huawei.com>
Subject: Re: [RFC] mtd: Fix error code loss in mtdchar_read() function.
Date: Mon, 25 Sep 2023 10:49:38 +0200 [thread overview]
Message-ID: <20230925104938.3f7b4284@xps-13> (raw)
In-Reply-To: <20230923005856.2538223-1-wangzhaolong1@huawei.com>
Hello,
Richard, your advice is welcome here.
wangzhaolong1@huawei.com wrote on Sat, 23 Sep 2023 08:58:56 +0800:
> In the first while loop, if the mtd_read() function returns -EBADMSG
s/the// s/function//
,
> and 'retlen' returns 0, the loop break and the function returns value
s/and// remains to 0. The loop breaks and the function
returns 'total_retlen' which is 0 instead of the error code.
> '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.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217939
> Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
> ---
> drivers/mtd/mtdchar.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 8dc4f5c493fc..ba60dc6bef98 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -211,7 +211,7 @@ static ssize_t mtdchar_read(struct file *file, char __user *buf, size_t count,
> }
>
> kfree(kbuf);
> - return total_retlen;
> + return total_retlen ? total_retlen : ret;
This is kind of wrong, if ret is 0 then you return ret while you should
return total_retlen. In practice it does not really matter, the result
is the same, but it makes it harder to understand the code IMHO.
> } /* mtdchar_read */
>
> static ssize_t mtdchar_write(struct file *file, const char __user *buf, size_t count,
Thanks,
Miquèl
next prev parent reply other threads:[~2023-09-25 8:49 UTC|newest]
Thread overview: 22+ 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-23 0:58 ` ZhaoLong Wang
2023-09-25 8:49 ` Miquel Raynal [this message]
2023-09-25 8:49 ` Miquel Raynal
2023-09-25 9:14 ` Richard Weinberger
2023-09-25 9:14 ` Richard Weinberger
2023-09-25 9:28 ` Miquel Raynal
2023-09-25 9:28 ` Miquel Raynal
2023-09-25 9:31 ` Richard Weinberger
2023-09-25 9:31 ` Richard Weinberger
2023-09-25 14:22 ` ZhaoLong Wang
2023-09-25 14:22 ` ZhaoLong Wang
2023-09-25 14:03 ` Richard Weinberger
2023-09-25 14:03 ` Richard Weinberger
2023-09-25 14:37 ` Miquel Raynal
2023-09-25 14:37 ` Miquel Raynal
2023-09-25 14:59 ` Richard Weinberger
2023-09-25 14:59 ` Richard Weinberger
2023-09-25 15:06 ` Miquel Raynal
2023-09-25 15:06 ` Miquel Raynal
2023-09-26 1:08 ` ZhaoLong Wang
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=20230925104938.3f7b4284@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=chengzhihao1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.