From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lithops.sigma-star.at (mailout.nod.at [116.203.167.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 458A229ACFD for ; Thu, 20 Aug 2026 18:58:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=116.203.167.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787252314; cv=none; b=BhZty9VzCYVrDBCkuBUDSxRjn23PfxMBm4Nn7R5pBVHtZWSmQqwAp8HsjRrEf/+VfLTOL+IUj21psPvWaXSp6qrUFig5wQplA9+P3fmO3rGKvoWh7SlC0IIVxXJxAA2/YA6rZHvAnVTrFTcdnl8Zxtwc+YAyFQPAdVB7Dz9vrJU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787252314; c=relaxed/simple; bh=ayHt9/4FwzKrDg9iddu/GDgO0Ck+y6dTREx+GlaBl2Q=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=Q5jEyzvmlO6nuUnhprcPJF7Tp9XFCkA1s4xe92vEn96MhFw6EvIIke8QaKqVT9FqPrHKHoV3FbrXtgr/7X8zk7+Ig5xhZOyhLpUmyQB2gLiwcnki36Ir/q8+/nQoMKRast5R7pDdjQuPLBjzfE6vl9666syQxxfRkuMN317on0I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at; spf=fail smtp.mailfrom=nod.at; arc=none smtp.client-ip=116.203.167.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nod.at Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 512771012D4; Thu, 20 Aug 2026 20:58:23 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZsNHtjgMfNLy; Thu, 20 Aug 2026 20:58:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 507CA2A3C71; Thu, 20 Aug 2026 20:58:22 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id K3J0EV3ouScX; Thu, 20 Aug 2026 20:58:22 +0200 (CEST) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id F345F1012D4; Thu, 20 Aug 2026 20:58:21 +0200 (CEST) Date: Thu, 20 Aug 2026 20:58:21 +0200 (CEST) From: Richard Weinberger To: zhouminqiang Cc: David Woodhouse , linux-mtd , linux-kernel , chengzhihao1 , yangerkun , yi zhang Message-ID: <852434244.6574.1787252301788.JavaMail.zimbra@nod.at> In-Reply-To: <20260820105003.2525647-1-zhouminqiang2@huawei.com> References: <20260820105003.2525647-1-zhouminqiang2@huawei.com> Subject: Re: [PATCH 0/6] jffs2: extend write verification to all write paths Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF153 (Linux)/8.8.12_GA_3809) Thread-Topic: jffs2: extend write verification to all write paths Thread-Index: ZdnguF3uAYb8KtTl3XluY4DRgs3IlQ== ----- Urspr=C3=BCngliche Mail ----- > Von: "zhouminqiang" > An: "David Woodhouse" , "richard" > CC: "linux-mtd" , "linux-kernel" , "chengzhihao1" > , "yangerkun" , "yi zhang"= > 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. >=20 > However, the current implementation only performs read-back verification > on write-buffer flush paths. Two scenarios remain uncovered: >=20 > 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. >=20 > 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. >=20 > This series covers both scenarios with the following changes. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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: >=20 > /sys/module/jffs2/parameters/write_verify >=20 > 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