From: Zhou Minqiang <zhouminqiang2@huawei.com>
To: linux@armlinux.org.uk, vz@mleia.com,
piotr.wojtaszczyk@timesys.com, maddy@linux.ibm.com,
dwmw2@infradead.org, richard@nod.at
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-mtd@lists.infradead.org, chengzhihao1@huawei.com,
yangerkun@huawei.com, yi.zhang@huawei.com,
zhouminqiang <zhouminqiang2@huawei.com>
Subject: [PATCH v4 2/8] jffs2: wbuf: fix OBSOLETE under-coverage on recovery failure
Date: Sun, 6 Sep 2026 11:03:38 +0800 [thread overview]
Message-ID: <20260906030344.2448622-3-zhouminqiang2@huawei.com> (raw)
In-Reply-To: <20260906030344.2448622-1-zhouminqiang2@huawei.com>
From: zhouminqiang <zhouminqiang2@huawei.com>
In jffs2_wbuf_recover(), when the recovery write to the new erase
block also fails, the code marks the already-written portion as
REF_OBSOLETE via jffs2_add_physical_node_ref(). However, the length
passed is ref_totlen(c, jeb, first_raw), which is the length of a
single node on the old block, rather than the full range of data
that was attempted to be written to the new block.
On the recovery target block the layout is:
ref_totlen(first_raw)
|<------------->|
ofs +---------------+-------+-------+ +--------+
| node 1 |node 2 |node 3 | ... |erased |
+---------------+-------+-------+ +--------+
| OBSOLETE | |
|<-towrite (page-aligned)->| |
|<-------- end - start -------->| |
|<-truly free->|
When the recovery buffer contains multiple nodes, ref_totlen only
accounts for the first node's length, which can be much smaller than
the total range. This under-deducts free_size, so the next write
lands at the start of node 2, which is already programmed on NAND,
and the AND operation corrupts both the old and new data.
With towrite as the OBSOLETE length, the next write lands right
after towrite in truly free space. However, node 3's header has
been written within the towrite region while its data extends beyond
it due to page-alignment truncation. On remount, the scanner finds
node 3's header, validates its CRC, and trusts its totlen -- skipping
PAD(totlen_node3) bytes. This skip extends past towrite into the
area where the subsequent write was placed, creating a shadow zone
that causes the newly written data to be silently lost.
Use end - start as the OBSOLETE length, which covers the full range
of data that was attempted to be written to the new block, so that
neither the NAND AND corruption nor the scanner shadow zone can
occur.
Fixes: b64335f2b740 ("[JFFS2] Add length argument to jffs2_add_physical_node_ref().")
Signed-off-by: zhouminqiang <zhouminqiang2@huawei.com>
---
fs/jffs2/wbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/jffs2/wbuf.c b/fs/jffs2/wbuf.c
index 61e3dbd4cd7b..ab247117ec77 100644
--- a/fs/jffs2/wbuf.c
+++ b/fs/jffs2/wbuf.c
@@ -437,7 +437,7 @@ static void jffs2_wbuf_recover(struct jffs2_sb_info *c)
kfree(buf);
if (retlen)
- jffs2_add_physical_node_ref(c, ofs | REF_OBSOLETE, ref_totlen(c, jeb, first_raw), NULL);
+ jffs2_add_physical_node_ref(c, ofs | REF_OBSOLETE, end-start, NULL);
c->wbuf_len = 0;
return;
--
2.52.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-09-06 3:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-06 3:03 [PATCH v4 0/8] jffs2: extend write verification to all write paths Zhou Minqiang
2026-09-06 3:03 ` [PATCH v4 1/8] jffs2: wbuf: clear wbuf on recovery failure paths Zhou Minqiang
2026-09-06 3:03 ` Zhou Minqiang [this message]
2026-09-06 3:03 ` [PATCH v4 3/8] jffs2: replace per-superblock verify buffer with per-write buffer Zhou Minqiang
2026-09-06 3:03 ` [PATCH v4 4/8] jffs2: write verify: add byte-by-byte comparison on mismatch Zhou Minqiang
2026-09-06 3:03 ` [PATCH v4 5/8] jffs2: add write verification to direct page writes in flash_writev Zhou Minqiang
2026-09-06 3:03 ` [PATCH v4 6/8] jffs2: add write verification to NOR direct write paths Zhou Minqiang
2026-09-06 3:03 ` [PATCH v4 7/8] jffs2: rename CONFIG_JFFS2_FS_WBUF_VERIFY to CONFIG_JFFS2_FS_WRITE_VERIFY Zhou Minqiang
2026-09-06 3:03 ` [PATCH v4 8/8] jffs2: add runtime toggle for write verification Zhou Minqiang
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=20260906030344.2448622-3-zhouminqiang2@huawei.com \
--to=zhouminqiang2@huawei.com \
--cc=chengzhihao1@huawei.com \
--cc=dwmw2@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=piotr.wojtaszczyk@timesys.com \
--cc=richard@nod.at \
--cc=vz@mleia.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