Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp9047562pxu; Mon, 28 Dec 2020 05:21:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJz3hu85HaERhsq0EUl5+MTao7P1cF2m0qRDBvUkeJLefJL4MmCbNHb1IQW4QGQvDcS1F5kw X-Received: by 2002:a05:6402:8cc:: with SMTP id d12mr41663973edz.0.1609161696169; Mon, 28 Dec 2020 05:21:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609161696; cv=none; d=google.com; s=arc-20160816; b=rss8YDoTlu+pLL1k44G26MH/0nourVPGiXS1f2DYlGlimSJ8/jdCmJpy+56AWEz9jV +bJ2n3rkn4eXu+wLy5bvh4jLjlzC1wp0DDaLa2LGXNHUSoey4te6O9fmqHzkWGwOFUP6 T6OsEbRiQJTkVaRd1ycLhohWvur3gWeNdOkvo0e+fWwgbEyu+Px8IZcMS7mDsfNyvzEE XGykd9HRjaDLEEE+fJIHGouDPWlK6XEbRJ4BYOjWsBdvaNzvi5w0ZZfKYNCP3F3hwCJ3 Uxw2Z8zshJebE33Cb/k6NyN0E1iQwiYr3P+mUXttQBNNs9ravBMaX7Q8A1MTJMBQv1pR pZvQ== 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=oFfmrX4lZZV2fekvyIu7OBdKiqRMHt8vEeUSHjYBjcLoRosvhFSyECeIGreo/c+Mfp GWn5a6egr5Au66Q2QZ5aaxbhX/vSbCcMxFifyr0dznbQgaug3ehXAUYCJ+J31pYEYo1m ZUy/xPRq0rPrD0hnBC1qsltDdX8jtr42d3ExNn3We37vmCnDpQLsyIYv1yT13hP74es7 FhqW0KCdPVWcjxZFt0aNfnIvczZ+KeZHofPX7vpaw5kjM1lehOhhalQf3FRdLLZS8Yx5 czk8tGOdAMbTWCxTRpYapzOjESZULuRPC76lYEaBIa3knfonrQpS6YHmRlgeKWk55+oU vhLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=HL1zOqcs; 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 f20si20420316edy.12.2020.12.28.05.21.12; Mon, 28 Dec 2020 05:21:36 -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=HL1zOqcs; 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 S2387476AbgL1NSM (ORCPT + 99 others); Mon, 28 Dec 2020 08:18:12 -0500 Received: from mail.kernel.org ([198.145.29.99]:46666 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387466AbgL1NSJ (ORCPT ); Mon, 28 Dec 2020 08:18:09 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 039A02076D; Mon, 28 Dec 2020 13:17:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609161448; bh=i7OZ7g5EYwwab0/iT21/W9zFYz9gbkRlmjrjXA+IToU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HL1zOqcsFw+8OYuMjSTN0ngsUo5cAhwLC/qLvUS8xV5wQWFSPVRMi+bT6L8nmULyj E7mCC9YRbvt6pFdOHX/r4Fai5iE6JUUH/35NJcWZ6V2V6qY2VHQXdgbuT4uBMekxCE RCZOLQl9YSF2FICPtPZxgHba5ehD1s4ngAEWj3LU= 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.14 217/242] jffs2: Fix GC exit abnormally Date: Mon, 28 Dec 2020 13:50:22 +0100 Message-Id: <20201228124915.352914906@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201228124904.654293249@linuxfoundation.org> References: <20201228124904.654293249@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);