Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp9040270pxu; Mon, 28 Dec 2020 05:10:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJxLaaDchkztJZgeNgFS3PExzqdxQa6ukh7kvke5eq00sPPQ3fFsRn5bQ6IuhBtVp0whuhVo X-Received: by 2002:a17:906:d8dc:: with SMTP id re28mr41860074ejb.168.1609161015522; Mon, 28 Dec 2020 05:10:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609161015; cv=none; d=google.com; s=arc-20160816; b=ibAU621KmBRjOInXXVeWdwg0fnw6ME9X0L3IWa7isqrPhKgxv6K3peXlz7+EVuqohw 0pAUmr7zTV1+ibf2/IpVLivXhxgDwvz+x7nl+jhXwjom4tL4y80sdWeaOU8CqAKoFLj7 xVb8YTEP2pnDxbZq5EHBJ8jw9HfXHRS8CSUy5YnALDIEVhIp0qtoGm1GGogmRIRK4AnC 5NE6w9490F2vtfaJ4YZ/OV83TJsjj/ikjMOxJRpBA+TgpCwmvy1KHFVEt51fAXb9tP05 js004M0EqIHCdAh3ZpqZ2U2TPuMG71ynWEWZz9j71xgRLkhY1bXPyUa6U3HdP3AEm9Bv mQnQ== 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=w5IMRYhk2mPY7u2jySF17IItKR+0BxldNTYTtBa2Urumu0HECG8mKwJP99p2KD2X53 FYaiekYNY/X3R7GUYivMn1/dSO0u+Ke2Lrz9ptRylKb8dMxrEluW2RIb6QZ4S7Pr0G4b 7lRzhWbfTqx7PUyozd6yzsYtAhVKKhIjYhBdE0Xak1omN4jIlP6iaZRpvPkRPFfvLVeA 5CY6irL71NKARCCwkb11SfS85w8QM+v8fLG80bn4E81Q5PgQO+jwc5LzWL2NIwACcV5i xRmnyG1MhtBqbtg7OX0K3pmvFc8/gkHuRqEujX6bDFLcn29IrOwPUZ390nd2Z0DOxxt4 I+GA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=aR1AhipC; 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 h24si4665817ejt.89.2020.12.28.05.09.52; Mon, 28 Dec 2020 05:10:15 -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=aR1AhipC; 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 S1730848AbgL1NII (ORCPT + 99 others); Mon, 28 Dec 2020 08:08:08 -0500 Received: from mail.kernel.org ([198.145.29.99]:35342 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730805AbgL1NHk (ORCPT ); Mon, 28 Dec 2020 08:07:40 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id EBEE022AAA; Mon, 28 Dec 2020 13:06:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609160819; bh=i7OZ7g5EYwwab0/iT21/W9zFYz9gbkRlmjrjXA+IToU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aR1AhipCDObhlfOnGu0ClVdtgrT7cPn1s3tIA3vH+MGuAzgGiCKn8Z65OiqhSIzc+ 1+qDJLJTYr37BzSGM86doW36GicIX+YNzbzjF+LxrYLWN4S48T2429z7Ky0sCsMUGy 6jbJ++bByC7+p7qlvkHVth5e8t6F1uhyaptkGe9k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zhe Li , Richard Weinberger Subject: [PATCH 4.9 159/175] jffs2: Fix GC exit abnormally Date: Mon, 28 Dec 2020 13:50:12 +0100 Message-Id: <20201228124900.943466481@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201228124853.216621466@linuxfoundation.org> References: <20201228124853.216621466@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);