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 3E2DC35B64C for ; Fri, 21 Aug 2026 06:31:33 +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=1787293897; cv=none; b=G/Wg5z7Jm0Vpwm9Y5+3Wlmkb1ZbDXEEfdWa5Iu32hdUb5YFwr8Bjre2i77rviWa/5XBZi3yMj/R1YQz7lvqvrKaKQR29wGAzZZD28P2NIQ/QXuVu0h/av9g/lIJiXNNXN8BrC4YdrMbV91FrdhSK5AOrN1fSRv419oFt6UeJCSw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787293897; c=relaxed/simple; bh=Q3fGDYQqCjZrNpxtT3swqIsSiTMFVUUs9WelGLcvs3Y=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=ujcDYncC9R5k8cE8uKQmyHf/4f7Ch5Aiwn2QKbsIshDT4j0Xt1cpHf9Hzolr4NFKjsQtZrc8HIiH8us74xKUzfiKM+A1LMzKLb+aVwoeuhLwRodqyNr4Uy82ocEhJoSN7hDK+1qZU5TirSQ6QVlM1D41R0KAebzHZq6YbS2hCe0= 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 BEB402698F4; Fri, 21 Aug 2026 08:31:31 +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 36vrECOgASb6; Fri, 21 Aug 2026 08:31:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 4D0982698F0; Fri, 21 Aug 2026 08:31:31 +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 jFQln7SZk_V7; Fri, 21 Aug 2026 08:31:31 +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 2F3D2317B49; Fri, 21 Aug 2026 08:31:31 +0200 (CEST) Date: Fri, 21 Aug 2026 08:31:30 +0200 (CEST) From: Richard Weinberger To: zhouminqiang Cc: David Woodhouse , linux-mtd , linux-kernel , chengzhihao1 , yangerkun , yi zhang Message-ID: <1421509427.8290.1787293890858.JavaMail.zimbra@nod.at> In-Reply-To: <2ca192b7-f903-41ba-8ffe-e8bfe9f79125@huawei.com> References: <20260820105003.2525647-1-zhouminqiang2@huawei.com> <852434244.6574.1787252301788.JavaMail.zimbra@nod.at> <2ca192b7-f903-41ba-8ffe-e8bfe9f79125@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: OKixXLUauFClroTi+LLJhjc4DHpniw== ----- Urspr=C3=BCngliche Mail ----- > Von: "zhouminqiang" > Thank you for your review and feedback. >=20 > Sorry for the confusion caused by my cover letter. We are not using > JFFS2 on NAND flash devices. Our primary goal is to extend write > verification to the NOR flash path because we have encountered data > corruption incidents in production environment and currently lack a > quick diagnostic tool to isolate the cause. While reviewing the > code flow, we noticed that the NAND buffered write path also lacked > verification, so we took the opportunity to extend it as well. >=20 > Although JFFS2 is in "Odd fixes" maintenance mode, there are still > a significant number of devices in production that rely on JFFS2, Okay, this makes more sense. > and we are encountering data corruption issues on live nodes. > Extending write verification to the NOR flash path would provide a > diagnostic tool for fault isolation. We notice that WBUF_VERIFY has > existed since 2007 (a6bc432e296d), so we want to extend the same > diagnostic facility to cover the write paths it missed, so that it > can serve ongoing product issue diagnosis. IMHO, this is a > debugging/maintenance feature, not introducing new functionality. >=20 > We respect your judgment and will leave the final decision to you. These days many patches are created by an LLM where people change software for the sake of changing. But if it solves a real problem you're facing in production things are diff= erent, of course. Please have a look at Sashiko review, maybe it's useful (maybe not...) and resend with an updated cover letter. Thanks, //richard