From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 36942C61DD6 for ; Sat, 29 Aug 2026 06:25:53 +0000 (UTC) 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=qiWTuJQyKE1+3Up+aB8+sEiHG1LQ+aR2dAtXbEE2WRs=; b=os56HzPgMuscWP K1eSwsJN1dCF1uyEHh9eaTrtt3j1OQtsUAy5EQuyRuQGHiJTyapX04bGL43CuxEkyFlAEEWmYivmS aOH9dfvsgkznmn0s/pjmNzvDGPnNfhgMdi1HmcEPbz+A1unemTgEyvtT41zDtr1/ttBVRaXxkf0lk dfkk+gw+0X00YMpKWfZe3tbt/VwUFiDnAPOavL4Vk7HeHHvZy+RX79XJKC2N0J3slgcSv0rxhtR6b X8+qgzxM0nZ8q9ua7utpRy7IBnEYFfaQgXXVijVwZGpO/7sAi7cq6+SlJcN3L71LPg46edUwZcEts cUTa9PAAxxecbi23vd6w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x0CVj-00000006mVk-1hmJ; Sat, 29 Aug 2026 06:25:51 +0000 Received: from canpmsgout04.his.huawei.com ([113.46.200.219]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x0CVa-00000006mPg-29kl; Sat, 29 Aug 2026 06:25:44 +0000 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=hbh66aOropGenQ0Z2GHHlKgM+3L4scXCa7L2SnI/vvU=; b=ypPEvvDDxhtb6fzDi/em1d1lCkxetpMf8OKOvk6mrLxSsMxbItSVNO7vdECe8um3YcBgEQ6EX WPsXkvC2cUJ6qnES+MLBbSbt8EjiXcKzx2j7ZPr9Qsxp/IYYSh7EiZq1VLu2ZmuU8EKn9JVFIjC 5ap8YAaSvILxpiYgr0L9Bks= Received: from mail.maildlp.com (unknown [172.19.163.0]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4hX4jD2SLxz1prKd; Sat, 29 Aug 2026 14:14:40 +0800 (CST) Received: from dggpemr100018.china.huawei.com (unknown [7.185.36.64]) by mail.maildlp.com (Postfix) with ESMTPS id 9A0C040537; Sat, 29 Aug 2026 14:25:29 +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; Sat, 29 Aug 2026 14:25:28 +0800 From: zhouminqiang To: , , , , , CC: , , , , , , Subject: [PATCH v2 0/7] jffs2: extend write verification to all write paths Date: Sat, 29 Aug 2026 14:16:50 +0800 Message-ID: <20260829061658.306854-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: kwepems100001.china.huawei.com (7.221.188.238) 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-20260828_232542_891316_1CA5FACD X-CRM114-Status: GOOD ( 13.02 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org 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: replace pre-allocated per-superblock wbuf_verify buffer with on-demand allocation inside jffs2_verify_write() - Patch 3: add byte-by-byte comparison after memcmp() mismatch to pinpoint the exact mismatch offset - Patch 4: add verification in jffs2_flash_writev() for the mtd_write() path that bypasses the write buffer - Patch 5: add verification calls in jffs2_flash_direct_write() and jffs2_flash_direct_writev() for NOR flash devices - Patch 6: rename CONFIG_JFFS2_FS_WBUF_VERIFY to CONFIG_JFFS2_FS_WRITE_VERIFY and remove the Kconfig dependency on CONFIG_JFFS2_FS_WRITEBUFFER - Patch 7: 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 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 (7): jffs2: wbuf: clear wbuf on recovery failure paths 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 | 91 +++------------ fs/jffs2/writev.c | 144 +++++++++++++++++++++++- 10 files changed, 198 insertions(+), 92 deletions(-) -- 2.52.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/