| Message ID | 20260901130549.1761342-1-zhouminqiang2@huawei.com |
|---|---|
| Headers | show
Return-Path:
<linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org>
X-Original-To: incoming@patchwork.ozlabs.org
Delivered-To: patchwork-incoming@legolas.ozlabs.org
Authentication-Results: legolas.ozlabs.org;
dkim=pass (2048-bit key;
secure) header.d=lists.infradead.org header.i=@lists.infradead.org
header.a=rsa-sha256 header.s=bombadil.20210309 header.b=0EcPUJ3x;
dkim=fail reason="signature verification failed" (1024-bit key;
unprotected) header.d=huawei.com header.i=@huawei.com header.a=rsa-sha256
header.s=dkim header.b=FGaTAERY;
dkim-atps=neutral
Authentication-Results: legolas.ozlabs.org;
spf=pass (sender SPF authorized) smtp.mailfrom=lists.infradead.org
(client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org;
envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org;
receiver=patchwork.ozlabs.org)
Received: from bombadil.infradead.org (bombadil.infradead.org
[IPv6:2607:7c80:54:3::133])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)
(No client certificate requested)
by legolas.ozlabs.org (Postfix) with ESMTPS id 4hZ5rz5Cnxz1y9v
for <incoming@patchwork.ozlabs.org>; Tue, 01 Sep 2026 23:13:21 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=lists.infradead.org; s=bombadil.20210309; h=Sender:
Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:
List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:CC
:To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:
Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:
List-Owner; bh=KtGC05RDXebuWj99nPF6KGguCAPW/XbWeI580XG543E=; b=0EcPUJ3x1CuI5F
jP93FStamdQcF2kAbBa7GDqVtk9xtkOOmxvzJLVDXHPnjqI2z0MXtFb2V0CBwUjClUon1B/NHeTOX
WpoqASPAMSaT23FdwDe5wi/Jr2Bkvs9+82pBOFQEFQVg13976Ru3/9yTPYtAyD4lyPGlENmcI5g87
qBUZIumTcNFdtYdjyrbs4DBjSLY1p/B2DBuhHkjdxkRUV6kUeeoJMFqaRz19XdfF4uDm2WJW6T8jL
JOIWAUKDL6KyH1nRMiskItivWNl87arngEOd2Ck7cm2jeuJ0aCAxjhzipfR5FQR8zRi7BJOzv2WgU
fZSjTGT908iAtTdGVLoA==;
Received: from localhost ([::1] helo=bombadil.infradead.org)
by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux))
id 1x1OIT-0000000CAYN-2oW7;
Tue, 01 Sep 2026 13:13:05 +0000
Received: from canpmsgout05.his.huawei.com ([113.46.200.220])
by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux))
id 1x1OIP-0000000CATy-2wOc;
Tue, 01 Sep 2026 13:13:04 +0000
dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim;
c=relaxed/relaxed; q=dns/txt;
h=From;
bh=nsDA+LJTa+8iJxzcAgvgwajibeJnEaZQX0TzVUG51qE=;
b=FGaTAERYcpC87ItXdrTqGuODCClix2oEWW9MjTK2x1194qw4uZwKwiTybEnmXdNSCVxYf/WI9
Pv60W/lnQEMQmj3o2O/Zwn44MBVuzHagc7hUkhXJVW5y6EzbEwQ2y0nzBZlgLJnvai3vMWQY7eK
VYaR4XBnt0PSpVoYZj1aS7w=
Received: from mail.maildlp.com (unknown [172.19.162.223])
by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4hZ5bM32Tnz12LF7;
Tue, 1 Sep 2026 21:01:35 +0800 (CST)
Received: from dggpemr100018.china.huawei.com (unknown [7.185.36.64])
by mail.maildlp.com (Postfix) with ESMTPS id 3D15B40561;
Tue, 1 Sep 2026 21:12:52 +0800 (CST)
Received: from huawei.com (10.50.85.155) by dggpemr100018.china.huawei.com
(7.185.36.64) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Tue, 1 Sep
2026 21:12:51 +0800
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 0/8] jffs2: extend write verification to all write paths
Date: Tue, 1 Sep 2026 21:05:41 +0800
Message-ID: <20260901130549.1761342-1-zhouminqiang2@huawei.com>
X-Mailer: git-send-email 2.52.0
MIME-Version: 1.0
X-Originating-IP: [10.50.85.155]
X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To
dggpemr100018.china.huawei.com (7.185.36.64)
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3
X-CRM114-CacheID: sfid-20260901_061302_352342_B8C795E6
X-CRM114-Status: GOOD ( 14.24 )
X-Spam-Score: -2.1 (--)
X-Spam-Report: Spam detection software,
running on the system "bombadil.infradead.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: When JFFS2 writes data to flash,
corruption can occur during
the write transfer (RAM failures,
bus errors) or after commit to the medium
(bit flips). To distinguish whether the corruption happened bef [...]
Content analysis details: (-2.1 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from
envelope-from domain
-0.1 DKIM_VALID Message has at least one valid DKIM or DK
signature
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.0 DMARC_PASS DMARC pass policy
X-BeenThere: linux-mtd@lists.infradead.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-mtd>,
<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd/>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "linux-mtd" <linux-mtd-bounces@lists.infradead.org>
Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org
|
| Series |
jffs2: extend write verification to all write paths
|
expand
|
When JFFS2 writes data to flash, corruption can occur during the write transfer (RAM failures, bus errors) or after commit to the medium (bit flips). To distinguish whether the corruption happened before or after the data reached the flash, 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. NOR flash devices write directly through jffs2_flash_direct_write() and jffs2_flash_direct_writev(), with no equivalent check. Data corruption incidents have been observed on NOR-based devices in production environments, yet there is no quick diagnostic tool to isolate whether the corruption occurred during the write transfer or after commit to the medium. A significant number of deployed devices rely on JFFS2 on NOR flash, making this gap a practical concern. During the investigation of the NOR flash gap, code inspection also revealed that when the write data length exceeds wbuf_pagesize in jffs2_flash_writev(), the excess data bypasses the write buffer and is written directly to flash via mtd_write(), with no verification. Additionally, jffs2_wbuf_recover() does not clear c->wbuf_len on recovery failure, which can lead to BUG_ON in jffs2_link_node_ref() or deadlock in jffs2_flush_wbuf_pad() on a subsequent write. This series closes these gaps with the following changes: - Patch 1: fix wbuf recovery failure exit paths to clear c->wbuf_len, preventing BUG_ON and deadlock - Patch 2: fix ref_totlen misuse in jffs2_wbuf_recover() failure path - Patch 3: replace pre-allocated per-superblock wbuf_verify buffer with on-demand allocation inside jffs2_verify_write() - Patch 4: add byte-by-byte comparison after memcmp() mismatch to pinpoint the exact mismatch offset - Patch 5: add verification in jffs2_flash_writev() for the mtd_write() path that bypasses the write buffer - Patch 6: add verification calls in jffs2_flash_direct_write() and jffs2_flash_direct_writev() for NOR flash devices - Patch 7: rename CONFIG_JFFS2_FS_WBUF_VERIFY to CONFIG_JFFS2_FS_WRITE_VERIFY and remove the Kconfig dependency on CONFIG_JFFS2_FS_WRITEBUFFER - Patch 8: add module parameter write_verify for runtime enable/disable of write verification This series extends the existing write verification mechanism to cover all write paths. It remains off by default and does not alter JFFS2's node CRC integrity checks. Changes in v3: - Add patch to fix incorrect ref_totlen usage in jffs2_wbuf_recover() secondary write failure path, which could corrupt free_size accounting - Add __GFP_NOWARN to jffs2_verify_write() kmalloc to suppres high-order allocation splats on large-erasesize NAND - Link to v2: https://lore.kernel.org/linux-mtd/20260829061658.306854-1-zhouminqiang2@huawei.com/T/#t Changes in v2: - Add patch to fix wbuf recovery failure exit paths not clearing c->wbuf_len, preventing BUG_ON and deadlock on subsequent writes - Use kmalloc() instead of vmalloc() for verify buffer allocation - Keep memcmp() on the hotpath and add byte-by-byte comparison only after a mismatch, rather than replacing memcmp() entirely - In jffs2_flash_direct_write() and jffs2_flash_direct_writev(), call mtd_write() before jffs2_sum_add_kvec() to prevent retlen from being uninitialized if jffs2_sum_add_kvec() causes an early return - Update defconfig files to rename CONFIG_JFFS2_FS_WBUF_VERIFY to CONFIG_JFFS2_FS_WRITE_VERIFY - Link to v1: https://lore.kernel.org/linux-mtd/20260820105003.2525647-1-zhouminqiang2@huawei.com/T/#t zhouminqiang (8): jffs2: wbuf: clear wbuf on recovery failure paths jffs2: wbuf: fix space accounting in recovery secondary write failure jffs2: replace per-superblock verify buffer with per-write buffer jffs2: write verify: add byte-by-byte comparison on mismatch jffs2: add write verification to direct page writes in flash_writev jffs2: add write verification to NOR direct write paths jffs2: rename CONFIG_JFFS2_FS_WBUF_VERIFY to CONFIG_JFFS2_FS_WRITE_VERIFY jffs2: add runtime toggle for write verification arch/arm/configs/keystone_defconfig | 2 +- arch/arm/configs/lpc32xx_defconfig | 2 +- arch/arm/configs/pxa3xx_defconfig | 2 +- arch/arm/configs/pxa_defconfig | 2 +- arch/powerpc/configs/44x/fsp2_defconfig | 2 +- fs/jffs2/Kconfig | 31 ++++- fs/jffs2/jffs2_fs_sb.h | 3 - fs/jffs2/os-linux.h | 11 ++ fs/jffs2/wbuf.c | 93 +++------------ fs/jffs2/writev.c | 144 +++++++++++++++++++++++- 10 files changed, 199 insertions(+), 93 deletions(-)