From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B67D0C433B4 for ; Sun, 9 May 2021 10:09:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 947BE6135A for ; Sun, 9 May 2021 10:09:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229593AbhEIKK0 (ORCPT ); Sun, 9 May 2021 06:10:26 -0400 Received: from wforward3-smtp.messagingengine.com ([64.147.123.22]:42783 "EHLO wforward3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229555AbhEIKK0 (ORCPT ); Sun, 9 May 2021 06:10:26 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailforward.west.internal (Postfix) with ESMTP id 75A221A0F; Sun, 9 May 2021 06:09:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 09 May 2021 06:09:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8/6Jfe j4vvCKvIBXVK1YriQu9GLr4oJ4B3+hOZ8c+AQ=; b=FvrV+t6xnFkK0Z+46nxj0L pt30miElkXULZHavfPdf57Fn/FL3luF6M88+EETZExEr+R1OUxOXqbomPgvEj4/H KRs3kwAMqTSJWapECwiUbtcp08DlikxU+G+GI6nAh7IS1ERlx6asZ5F5jBJqC46h BkQ1luOaZju3LDzk934+QivV+TJMO1heIZzJHrHZrWCLk8lcGLtANUcf5TkQ+T43 xEZ7ko0UlDweYI4zhtn2wFh0nFOu5ApMTe8LAAZ9nIh7LvHbqronTex5BjtQoIwx E+Q0BT2CGX3qmjKW41pVqew+o+xhYLFM0KcU3eqNZKKmIApc38n1HAYlMBoammoA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdegiedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvffhfffkgggtgfesthekredttd dtlfenucfhrhhomhepoehgrhgvghhkhheslhhinhhugihfohhunhgurghtihhonhdrohhr gheqnecuggftrfgrthhtvghrnhepieetveehuedvhfdtgfdvieeiheehfeelveevheejud etveeuveeludejjefgteehnecukfhppeekfedrkeeirdejgedrieegnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhrvghgsehkrhhorghhrd gtohhm X-ME-Proxy: Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 9 May 2021 06:09:22 -0400 (EDT) Subject: FAILED: patch "[PATCH] ubifs: Only check replay with inode type to judge if inode" failed to apply to 4.14-stable tree To: guochun.mao@mediatek.com, richard@nod.at Cc: From: Date: Sun, 09 May 2021 12:09:13 +0200 Message-ID: <1620554953167129@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 3e903315790baf4a966436e7f32e9c97864570ac Mon Sep 17 00:00:00 2001 From: Guochun Mao Date: Tue, 16 Mar 2021 16:52:14 +0800 Subject: [PATCH] ubifs: Only check replay with inode type to judge if inode linked Conside the following case, it just write a big file into flash, when complete writing, delete the file, and then power off promptly. Next time power on, we'll get a replay list like: ... LEB 1105:211344 len 4144 deletion 0 sqnum 428783 key type 1 inode 80 LEB 15:233544 len 160 deletion 1 sqnum 428785 key type 0 inode 80 LEB 1105:215488 len 4144 deletion 0 sqnum 428787 key type 1 inode 80 ... In the replay list, data nodes' deletion are 0, and the inode node's deletion is 1. In current logic, the file's dentry will be removed, but inode and the flash space it occupied will be reserved. User will see that much free space been disappeared. We only need to check the deletion value of the following inode type node of the replay entry. Fixes: e58725d51fa8 ("ubifs: Handle re-linking of inodes correctly while recovery") Cc: stable@vger.kernel.org Signed-off-by: Guochun Mao Signed-off-by: Richard Weinberger diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c index 0f8a6a16421b..1929ec63a0cb 100644 --- a/fs/ubifs/replay.c +++ b/fs/ubifs/replay.c @@ -223,7 +223,8 @@ static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino) */ list_for_each_entry_reverse(r, &c->replay_list, list) { ubifs_assert(c, r->sqnum >= rino->sqnum); - if (key_inum(c, &r->key) == key_inum(c, &rino->key)) + if (key_inum(c, &r->key) == key_inum(c, &rino->key) && + key_type(c, &r->key) == UBIFS_INO_KEY) return r->deletion == 0; }