From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Bence Csókás" <csokas.bence@prolan.hu>
Cc: <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>
Subject: Re: [PATCH v3] mtd: Verify written data in paranoid mode
Date: Mon, 12 May 2025 11:14:25 +0200 [thread overview]
Message-ID: <87frhambri.fsf@bootlin.com> (raw)
In-Reply-To: <20250512084033.69718-1-csokas.bence@prolan.hu> ("Bence Csókás"'s message of "Mon, 12 May 2025 10:40:32 +0200")
On 12/05/2025 at 10:40:32 +02, Bence Csókás <csokas.bence@prolan.hu> wrote:
> Add MTD_PARANOID config option for verifying all written data to prevent
> silent bit errors being undetected, at the cost of some bandwidth overhead.
>
> Signed-off-by: Bence Csókás <csokas.bence@prolan.hu>
> ---
> drivers/mtd/Kconfig | 14 ++++++++++++
> drivers/mtd/mtdcore.c | 51 +++++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 63 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index 796a2eccbef0..e75f4a57df6a 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -206,6 +206,20 @@ config MTD_PARTITIONED_MASTER
> the parent of the partition device be the master device, rather than
> what lies behind the master.
>
> +config MTD_PARANOID
> + bool "Read back written data (paranoid mode)"
> + help
> + This option makes the MTD core read back all data on a write and
> + report an error if it doesn't match the written data. This can
> + safeguard against silent bit errors resulting from a faulty Flash,
> + controller oddities, bus noise etc.
> +
> + It is up to the layer above MTD (e.g. the filesystem) to handle
> + this condition, for example by going read-only to prevent further
> + data corruption, or to mark a certain region of Flash as bad.
> +
> + If you are unsure, select 'n'.
> +
> source "drivers/mtd/chips/Kconfig"
>
> source "drivers/mtd/maps/Kconfig"
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 5ba9a741f5ac..3f9874cd4126 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -1745,8 +1745,8 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops)
> }
> EXPORT_SYMBOL_GPL(mtd_read_oob);
>
> -int mtd_write_oob(struct mtd_info *mtd, loff_t to,
> - struct mtd_oob_ops *ops)
> +static int _mtd_write_oob(struct mtd_info *mtd, loff_t to,
> + struct mtd_oob_ops *ops)
I don't like these '_' prefixes, they do not indicate much about the
content of the function. I don't think we need an extra function for
that, just include the check in mtd_write_oob?
> {
> struct mtd_info *master = mtd_get_master(mtd);
> int ret;
> @@ -1771,6 +1771,53 @@ int mtd_write_oob(struct mtd_info *mtd, loff_t to,
>
> return mtd_write_oob_std(mtd, to, ops);
> }
> +
> +static int _mtd_verify(struct mtd_info *mtd, loff_t to, size_t len, const u8 *buf)
> +{
> + struct device *dev = &mtd->dev;
> + u_char *verify_buf;
> + size_t r_retlen;
> + int ret;
> +
> + verify_buf = devm_kmalloc(dev, len, GFP_KERNEL);
> + if (!verify_buf)
> + return -ENOMEM;
> +
> + ret = mtd_read(mtd, to, len, &r_retlen, verify_buf);
> + if (ret < 0)
> + goto err;
> +
> + if (len != r_retlen) {
> + /* We shouldn't see short reads */
> + dev_err(dev, "Verify failed, written %zd but only read %zd",
> + len, r_retlen);
> + ret = -EIO;
> + goto err;
> + }
> +
> + if (memcmp(verify_buf, buf, len)) {
> + dev_err(dev, "Verify failed, compare mismatch!");
> + ret = -EIO;
> + }
> +
> +err:
> + devm_kfree(dev, verify_buf);
> + return ret;
> +}
> +
> +int mtd_write_oob(struct mtd_info *mtd, loff_t to,
> + struct mtd_oob_ops *ops)
> +{
> + int ret = _mtd_write_oob(mtd, to, ops);
> +
> + if (ret < 0)
> + return ret;
> +
> + if (IS_ENABLED(CONFIG_MTD_PARANOID))
> + ret = _mtd_verify(mtd, to, ops->retlen, ops->datbuf);
Why _mtd_verify and not mtd_verify?
______________________________________________________
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: "Bence Csókás" <csokas.bence@prolan.hu>
Cc: <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>
Subject: Re: [PATCH v3] mtd: Verify written data in paranoid mode
Date: Mon, 12 May 2025 11:14:25 +0200 [thread overview]
Message-ID: <87frhambri.fsf@bootlin.com> (raw)
In-Reply-To: <20250512084033.69718-1-csokas.bence@prolan.hu> ("Bence Csókás"'s message of "Mon, 12 May 2025 10:40:32 +0200")
On 12/05/2025 at 10:40:32 +02, Bence Csókás <csokas.bence@prolan.hu> wrote:
> Add MTD_PARANOID config option for verifying all written data to prevent
> silent bit errors being undetected, at the cost of some bandwidth overhead.
>
> Signed-off-by: Bence Csókás <csokas.bence@prolan.hu>
> ---
> drivers/mtd/Kconfig | 14 ++++++++++++
> drivers/mtd/mtdcore.c | 51 +++++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 63 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index 796a2eccbef0..e75f4a57df6a 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -206,6 +206,20 @@ config MTD_PARTITIONED_MASTER
> the parent of the partition device be the master device, rather than
> what lies behind the master.
>
> +config MTD_PARANOID
> + bool "Read back written data (paranoid mode)"
> + help
> + This option makes the MTD core read back all data on a write and
> + report an error if it doesn't match the written data. This can
> + safeguard against silent bit errors resulting from a faulty Flash,
> + controller oddities, bus noise etc.
> +
> + It is up to the layer above MTD (e.g. the filesystem) to handle
> + this condition, for example by going read-only to prevent further
> + data corruption, or to mark a certain region of Flash as bad.
> +
> + If you are unsure, select 'n'.
> +
> source "drivers/mtd/chips/Kconfig"
>
> source "drivers/mtd/maps/Kconfig"
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 5ba9a741f5ac..3f9874cd4126 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -1745,8 +1745,8 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops)
> }
> EXPORT_SYMBOL_GPL(mtd_read_oob);
>
> -int mtd_write_oob(struct mtd_info *mtd, loff_t to,
> - struct mtd_oob_ops *ops)
> +static int _mtd_write_oob(struct mtd_info *mtd, loff_t to,
> + struct mtd_oob_ops *ops)
I don't like these '_' prefixes, they do not indicate much about the
content of the function. I don't think we need an extra function for
that, just include the check in mtd_write_oob?
> {
> struct mtd_info *master = mtd_get_master(mtd);
> int ret;
> @@ -1771,6 +1771,53 @@ int mtd_write_oob(struct mtd_info *mtd, loff_t to,
>
> return mtd_write_oob_std(mtd, to, ops);
> }
> +
> +static int _mtd_verify(struct mtd_info *mtd, loff_t to, size_t len, const u8 *buf)
> +{
> + struct device *dev = &mtd->dev;
> + u_char *verify_buf;
> + size_t r_retlen;
> + int ret;
> +
> + verify_buf = devm_kmalloc(dev, len, GFP_KERNEL);
> + if (!verify_buf)
> + return -ENOMEM;
> +
> + ret = mtd_read(mtd, to, len, &r_retlen, verify_buf);
> + if (ret < 0)
> + goto err;
> +
> + if (len != r_retlen) {
> + /* We shouldn't see short reads */
> + dev_err(dev, "Verify failed, written %zd but only read %zd",
> + len, r_retlen);
> + ret = -EIO;
> + goto err;
> + }
> +
> + if (memcmp(verify_buf, buf, len)) {
> + dev_err(dev, "Verify failed, compare mismatch!");
> + ret = -EIO;
> + }
> +
> +err:
> + devm_kfree(dev, verify_buf);
> + return ret;
> +}
> +
> +int mtd_write_oob(struct mtd_info *mtd, loff_t to,
> + struct mtd_oob_ops *ops)
> +{
> + int ret = _mtd_write_oob(mtd, to, ops);
> +
> + if (ret < 0)
> + return ret;
> +
> + if (IS_ENABLED(CONFIG_MTD_PARANOID))
> + ret = _mtd_verify(mtd, to, ops->retlen, ops->datbuf);
Why _mtd_verify and not mtd_verify?
next prev parent reply other threads:[~2025-05-12 9:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-12 8:40 [PATCH v3] mtd: Verify written data in paranoid mode Bence Csókás
2025-05-12 8:40 ` Bence Csókás
2025-05-12 9:14 ` Miquel Raynal [this message]
2025-05-12 9:14 ` Miquel Raynal
2025-05-12 9:45 ` Richard Weinberger
2025-05-12 9:45 ` Richard Weinberger
2025-05-12 12:29 ` Csókás Bence
2025-05-12 12:29 ` Csókás Bence
2025-05-12 12:47 ` Richard Weinberger
2025-05-12 12:47 ` Richard Weinberger
2025-05-12 13:13 ` Csókás Bence
2025-05-12 13:13 ` Csókás Bence
2025-05-12 13:59 ` Miquel Raynal
2025-05-12 13:59 ` Miquel Raynal
2025-05-12 15:23 ` Richard Weinberger
2025-05-12 15:23 ` Richard Weinberger
2025-05-12 15:33 ` Miquel Raynal
2025-05-12 15:33 ` Miquel Raynal
2025-05-12 15:51 ` Csókás Bence
2025-05-12 15:51 ` Csókás Bence
2025-05-12 15:57 ` Richard Weinberger
2025-05-12 15:57 ` Richard Weinberger
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=87frhambri.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=csokas.bence@prolan.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=vigneshr@ti.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.