[PATCH 0/6] jffs2: extend write verification to all write paths

[zhouminqiang]

Thank you for your review and feedback.

Sorry for the confusion caused by my cover letter. We are not using
JFFS2 on NAND flash devices. Our primary goal is to extend write
verification to the NOR flash path because we have encountered data
corruption incidents in production environment and currently lack a
quick diagnostic tool to isolate the cause. While reviewing the
code flow, we noticed that the NAND buffered write path also lacked
verification, so we took the opportunity to extend it as well.

Although JFFS2 is in "Odd fixes" maintenance mode, there are still
a significant number of devices in production that rely on JFFS2,
and we are encountering data corruption issues on live nodes.
Extending write verification to the NOR flash path would provide a
diagnostic tool for fault isolation. We notice that WBUF_VERIFY has
existed since 2007 (a6bc432e296d), so we want to extend the same
diagnostic facility to cover the write paths it missed, so that it
can serve ongoing product issue diagnosis. IMHO, this is a
debugging/maintenance feature, not introducing new functionality.

We respect your judgment and will leave the final decision to you.

在 2026/8/21 2:58, Richard Weinberger 写道:
> ----- Ursprüngliche Mail -----
>> Von: "zhouminqiang" <zhouminqiang2 at huawei.com>
>> An: "David Woodhouse" <dwmw2 at infradead.org>, "richard" <richard at nod.at>
>> CC: "linux-mtd" <linux-mtd at lists.infradead.org>, "linux-kernel" <linux-kernel at vger.kernel.org>, "chengzhihao1"
>> <chengzhihao1 at huawei.com>, "yangerkun" <yangerkun at huawei.com>, "yi zhang" <yi.zhang at huawei.com>
>> Gesendet: Donnerstag, 20. August 2026 12:49:56
>> Betreff: [PATCH 0/6] jffs2: extend write verification to all write paths
> 
>> When JFFS2 writes data to flash, it first calculates a node CRC, and
>> the NAND controller calculates ECC as the data is programmed. If
> 
> Why would one use JFFS2 in 2026 on NAND flash?
> 
>> corruption occurs between these two points, the possible causes are
>> RAM failures or bus transfer errors before the data reaches the flash,
>> or bit flips on the flash medium itself. To distinguish whether the
>> corruption happened during the write transfer or after commit to the
>> medium, commit a6bc432e296d ("[JFFS2] Add support for write-buffer
>> verification") introduced CONFIG_JFFS2_FS_WBUF_VERIFY: reading the
>> data back immediately after a successful write and comparing it with
>> the in-memory source buffer provides the missing observation point
>> for that diagnosis.
>>
>> However, the current implementation only performs read-back verification
>> on write-buffer flush paths. Two scenarios remain uncovered:
>>
>>   1. When the write data length exceeds wbuf_pagesize, the excess data
>>   bypasses the write buffer and is written directly to flash via
>>   mtd_write() in jffs2_flash_writev(), with no verification.
>>   2. NOR Flash and other non-writebuffered devices write directly through
>>   jffs2_flash_direct_write() and jffs2_flash_direct_writev(), with no
>>   equivalent check.
>>
>> In both cases, if MTD reports a successful write but the readable medium
>> differs from JFFS2's source buffer, a later node CRC failure cannot
>> distinguish transport/program-time corruption from post-commit media
>> damage, defeating the original diagnostic intent.
>>
>> This series covers both scenarios with the following changes.
>>
>> Replace the pre-allocated per-superblock wbuf_verify buffer with
>> on-demand allocation inside jffs2_verify_write(). This allows
>> concurrent verification calls to proceed independently without
>> contending for a shared buffer. Additionally, memcmp() is replaced
>> with a byte-by-byte comparison that pinpoints the exact mismatch
>> offset, rather than merely reporting equal or not-equal.
>>
>> Add verification calls in jffs2_flash_writev() for direct page
>> writes, and in jffs2_flash_direct_write() and
>> jffs2_flash_direct_writev() for NOR and other non-writebuffered
>> devices.
>>
>> Since verification now covers all write paths rather than only the
>> write-buffer path, rename CONFIG_JFFS2_FS_WBUF_VERIFY to
>> CONFIG_JFFS2_FS_WRITE_VERIFY and remove the Kconfig dependency on
>> CONFIG_JFFS2_FS_WRITEBUFFER.
>>
>> Add a module parameter write_verify (default off, 0644) to allow
>> dynamic enable/disable of write verification at runtime, so kernels
>> can carry the diagnostic facility without read-back overhead until
>> fault isolation is required. The parameter can be accessed through:
>>
>>     /sys/module/jffs2/parameters/write_verify
>>
>> This remains an optional diagnostic aid; node CRCs continue to provide
>> JFFS2's normal on-media integrity check.
> 
> Please explain why this is needed.
> JFFS2 is in "Odd fixes" maintenance mode.
> It never worked well for NAND flash, that's why UBIFS (JFFS3) was born.
> 
> Thanks,
> //richard