From: zhouminqiang <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>
Subject: [PATCH v3 2/8] jffs2: wbuf: fix space accounting in recovery secondary write failure
Date: Tue, 1 Sep 2026 21:05:43 +0800 [thread overview]
Message-ID: <20260901130549.1761342-3-zhouminqiang2@huawei.com> (raw)
In-Reply-To: <20260901130549.1761342-1-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, not retlen which is the actual number of bytes written to
the new block.
When the recovery buffer contains multiple nodes, ref_totlen only
accounts for the first node's length, which can be much smaller than
retlen. This under-deducts free_size, causing subsequent allocations to
land on already-programmed NAND pages and silently corrupt data. When
first_raw is the only node in the recovery range, ref_totlen equals the
full unaligned data size and exceeds the page-aligned retlen,
over-deducting free_size and wasting space.
Use retlen so the new block's free_size accurately reflects which NAND
pages have been programmed.
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..360a291d9fd5 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, retlen, NULL);
c->wbuf_len = 0;
return;
--
2.52.0
next prev parent reply other threads:[~2026-09-01 13:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 13:05 [PATCH v3 0/8] jffs2: extend write verification to all write paths zhouminqiang
2026-09-01 13:05 ` [PATCH v3 1/8] jffs2: wbuf: clear wbuf on recovery failure paths zhouminqiang
2026-09-01 13:05 ` zhouminqiang [this message]
2026-09-01 13:05 ` [PATCH v3 3/8] jffs2: replace per-superblock verify buffer with per-write buffer zhouminqiang
2026-09-01 13:05 ` [PATCH v3 4/8] jffs2: write verify: add byte-by-byte comparison on mismatch zhouminqiang
2026-09-01 13:05 ` [PATCH v3 5/8] jffs2: add write verification to direct page writes in flash_writev zhouminqiang
2026-09-01 13:05 ` [PATCH v3 6/8] jffs2: add write verification to NOR direct write paths zhouminqiang
2026-09-01 13:05 ` [PATCH v3 7/8] jffs2: rename CONFIG_JFFS2_FS_WBUF_VERIFY to CONFIG_JFFS2_FS_WRITE_VERIFY zhouminqiang
2026-09-01 13:05 ` [PATCH v3 8/8] jffs2: add runtime toggle for write verification zhouminqiang
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=20260901130549.1761342-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