Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp9103375pxu; Mon, 28 Dec 2020 06:43:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJw5v0OOigH0dU8rTP02deXAe5eFsVOk35izNr4v4GoxzooEDFJa+q/OeCJ7hJOxBZxcoC5V X-Received: by 2002:aa7:c3d3:: with SMTP id l19mr43657886edr.366.1609166601942; Mon, 28 Dec 2020 06:43:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609166601; cv=none; d=google.com; s=arc-20160816; b=k0Jyxtq75D9wVvIAwZgDCuDZwL/FqiBYwUrEbYpWOCrwhHlhP6CjwHGZX7N9++fiXV xXeqA0wadu9e7zouAhYHMVsMw0dDOJEVbs4qOMBj7msfrCgI4OZ5OhiVMT6ZyA2yiChY ndec2FQon88ef126AzAw9ECBihPLwfawK/xiInKlAu53G4kT9Wvc+p4O4lSDjJ8kdRP9 zaRI/2XgBslVcqoar1G6YHoZ59DbedwkXBN31LhrOydre9daqwbeoo4Wh79vqPvF3whe 3U/0iyH5gyXqWYKzDltx6TNWmRdv0fiafAPpXtKn6/4Ao7T3Y8NVjE0PEqnZVy57Nm+w F3fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=H86DkxYz8M75xSJuyppYNBPWm/9aP9F2D4r6vydwB7A=; b=uwDu35bnWWe4tgh9vrfljMR4OmksAEREMAgYlkByl65db4HY8qK8tN4ET42qfUB1SU Rb5NXBJQVEudH8Qkm5J1Cc7TGe263ETWi6qWhZa+X6pUEFCdZw/raw1sptltqh/nxGaa oWx+PBSH6hOXRFB6atj/wqOJR/Opj0guxuQt0s+dQSwBKaWu2C2I6MczJCVJapCgUtVF zSb4bUW/vzV8oQwoHzyV2ICXPcfEXEGf15nuTqGYTqQc31RvXbAQdlnmION5XUcQ6E0u ezp0oP/ONpllXWuo0wzCVtMul72w9NexPWRBX7gkORGp7bA82rZ8I6Ci2QoUjhDFYgGS lnsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=zIki16rl; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lr8si2141151ejb.29.2020.12.28.06.42.59; Mon, 28 Dec 2020 06:43:21 -0800 (PST) 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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=zIki16rl; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2505802AbgL1OkS (ORCPT + 99 others); Mon, 28 Dec 2020 09:40:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:36896 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2503372AbgL1O3I (ORCPT ); Mon, 28 Dec 2020 09:29:08 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 82BB320731; Mon, 28 Dec 2020 14:28:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609165708; bh=i7OZ7g5EYwwab0/iT21/W9zFYz9gbkRlmjrjXA+IToU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zIki16rlR7gxCMXd7h5hPR3DI2//FRS1ElkTpyA6YIzVZbIZ0VScH21sMracQFYZZ r2gnouYjaM2qeNZoI4Bwb0OZiA74q0cU75oMSrthbZ4dov/Kl1EIDuNMcBBtJ915+5 qjhlRLjob1BE1CMJQGkD03406oxg7C9kYw5lTorI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zhe Li , Richard Weinberger Subject: [PATCH 5.10 627/717] jffs2: Fix GC exit abnormally Date: Mon, 28 Dec 2020 13:50:25 +0100 Message-Id: <20201228125050.960832948@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201228125020.963311703@linuxfoundation.org> References: <20201228125020.963311703@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Zhe Li commit 9afc9a8a4909fece0e911e72b1060614ba2f7969 upstream. The log of this problem is: jffs2: Error garbage collecting node at 0x***! jffs2: No space for garbage collection. Aborting GC thread This is because GC believe that it do nothing, so it abort. After going over the image of jffs2, I find a scene that can trigger this problem stably. The scene is: there is a normal dirent node at summary-area, but abnormal at corresponding not-summary-area with error name_crc. The reason that GC exit abnormally is because it find that abnormal dirent node to GC, but when it goes to function jffs2_add_fd_to_list, it cannot meet the condition listed below: if ((*prev)->nhash == new->nhash && !strcmp((*prev)->name, new->name)) So no node is marked obsolete, statistical information of erase_block do not change, which cause GC exit abnormally. The root cause of this problem is: we do not check the name_crc of the abnormal dirent node with summary is enabled. Noticed that in function jffs2_scan_dirent_node, we use function jffs2_scan_dirty_space to deal with the dirent node with error name_crc. So this patch add a checking code in function read_direntry to ensure the correctness of dirent node. If checked failed, the dirent node will be marked obsolete so GC will pass this node and this problem will be fixed. Cc: Signed-off-by: Zhe Li Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman --- fs/jffs2/readinode.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --- a/fs/jffs2/readinode.c +++ b/fs/jffs2/readinode.c @@ -672,6 +672,22 @@ static inline int read_direntry(struct j jffs2_free_full_dirent(fd); return -EIO; } + +#ifdef CONFIG_JFFS2_SUMMARY + /* + * we use CONFIG_JFFS2_SUMMARY because without it, we + * have checked it while mounting + */ + crc = crc32(0, fd->name, rd->nsize); + if (unlikely(crc != je32_to_cpu(rd->name_crc))) { + JFFS2_NOTICE("name CRC failed on dirent node at" + "%#08x: read %#08x,calculated %#08x\n", + ref_offset(ref), je32_to_cpu(rd->node_crc), crc); + jffs2_mark_node_obsolete(c, ref); + jffs2_free_full_dirent(fd); + return 0; + } +#endif } fd->nhash = full_name_hash(NULL, fd->name, rd->nsize);