Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp150979ybg; Mon, 8 Jun 2020 19:13:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzFlLRTusIPd6QAAx5E65ZupzWN2jZYEHZt5XpETJAqZlyanUWXxR+4sn7WsR8tfK5XKidD X-Received: by 2002:a50:a721:: with SMTP id h30mr22849101edc.153.1591668837809; Mon, 08 Jun 2020 19:13:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591668837; cv=none; d=google.com; s=arc-20160816; b=YO0okQj8D+tjeNDI7kf+Z2q3gO5YYSoQrkBaLPAFOywny/k00y5LlwnwYGUd3NK9AP D2bLWm3GoJy5eL79yfh2krRxrI4upe6xUAOljJzgJfIu4ePm0iBuajLc14QMfKSmezMD XDZnQ9/G73W+lLKZ9SUJpbEIwQK2xtoGYUzNUitL1pk2LENJkE7oV+M+JFOOTnM1dM+7 tFKGcoYoHv+tRMcmqBOYHrpvuCwWoHhsJoUHEztN/ImwTp0CVl91g5eg5PTBzyKazZ9r GBV01QBA1qbB/AD+2+VRndAxFScHTu895a5WYGHg8kqnOES9LhQjgpxU3IJb/CysaJch o4WQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=6Hjp9bGrdz5pxhaROfPFGGzpm2dyN0rUBT1x3i/O0rA=; b=zDYE/wROHkykhdZEWfdDOoZ2RA6lPZ9qDMuuqkgQboQIAhaVw+2JBPZwNFbM8lzdJn AKMyy98WwbYnyeDX30r3bEtknV/3uWU0NRG6yKer2TiJWFZfzTme1t6nrcTiSQvgfxFz /7VzJzBffqfkzRHZEyjVa3ONw5pdN9/+5INzzOf+blJR2hU/zP+UwzlFnxs7Ko2RVnaN kTao7TT89tlXzJuTssWwmqoIDM1qFXHliJ+y135W9nMQ1aMd18jAej+guvbJrS25Xock ydsbVTKT9uFi5YgRy/HrQcTweVLPAWH0DzmV80tp+IVKforqYLyY8R2yuQPhKw/zxVlb fwsw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk4si9617416ejb.257.2020.06.08.19.13.34; Mon, 08 Jun 2020 19:13:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726966AbgFICJk (ORCPT + 99 others); Mon, 8 Jun 2020 22:09:40 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:56538 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726749AbgFICJj (ORCPT ); Mon, 8 Jun 2020 22:09:39 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id BE9B8658380F5715FC5F; Tue, 9 Jun 2020 10:09:35 +0800 (CST) Received: from DESKTOP-FKFNUOQ.china.huawei.com (10.67.101.2) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.487.0; Tue, 9 Jun 2020 10:09:27 +0800 From: Zhe Li To: CC: , , , , , Subject: [PATCH v3] jffs2: fix jffs2 mounting failure Date: Tue, 9 Jun 2020 10:09:27 +0800 Message-ID: <20200609020927.68460-1-lizhe67@huawei.com> X-Mailer: git-send-email 2.21.0.windows.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.67.101.2] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for the advice mentioned in the email. This is my v3 patch for this problem. Mounting jffs2 on nand flash will get message "failed: I/O error" with the steps listed below. 1.umount jffs2 2.erase nand flash 3.mount jffs2 on it (this mounting operation will be successful) 4.do chown or chmod to the mount point directory 5.umount jffs2 6.mount jffs2 on nand flash After step 6, we will get message "mount ... failed: I/O error". Typical image of this problem is like: Empty space found from 0x00000000 to 0x008a0000 Inode node at xx, totlen 0x00000044, #ino 1, version 1, isize 0... The reason for this mounting failure is that at the end of function jffs2_scan_medium(), jffs2 will check the used_size and some info of nr_blocks.If conditions are met, it will return -EIO. The detail is that, in the steps listed above, step 4 will write jffs2_raw_inode into flash without jffs2_raw_dirent, which will cause that there are some jffs2_raw_inode but no jffs2_raw_dirent on flash. This will meet the condition at the end of function jffs2_scan_medium() and return -EIO if we umount jffs2 and mount it again. We notice that jffs2 add the value of c->unchecked_size if we find an inode node while mounting. And jffs2 will never add the value of c->unchecked_size in other situations. So this patch add one more condition about c->unchecked_size of the judgement to fix this problem. Signed-off-by: Zhe Li --- fs/jffs2/scan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c index 5f7e284..db72a9d 100644 --- a/fs/jffs2/scan.c +++ b/fs/jffs2/scan.c @@ -261,7 +261,8 @@ int jffs2_scan_medium(struct jffs2_sb_info *c) } #endif if (c->nr_erasing_blocks) { - if ( !c->used_size && ((c->nr_free_blocks+empty_blocks+bad_blocks)!= c->nr_blocks || bad_blocks == c->nr_blocks) ) { + if (!c->used_size && !c->unchecked_size && + ((c->nr_free_blocks+empty_blocks+bad_blocks) != c->nr_blocks || bad_blocks == c->nr_blocks)) { pr_notice("Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes\n"); pr_notice("empty_blocks %d, bad_blocks %d, c->nr_blocks %d\n", empty_blocks, bad_blocks, c->nr_blocks); -- 2.7.4