Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4214680pxf; Tue, 16 Mar 2021 08:12:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwO7vUETT5AsJtss+GXebXrNX1P4ArdcCdVpzPSnrTXaXtCHWIPSl9kYjIjpspfPo4Sm/Vk X-Received: by 2002:a17:906:a413:: with SMTP id l19mr30407526ejz.421.1615907569132; Tue, 16 Mar 2021 08:12:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615907569; cv=none; d=google.com; s=arc-20160816; b=XZeaHKdaIANE+l1gbwfdeQX2VEjGQKOMOJNoFx3bEozrhb4sqdPBQ9QSFJHsDg0C/W 6FVopJz5uh3sIWezpPZU+Y22VvpCXPpu90eoSMHOhWLBDjwqK/0Tss5MWPZ5lrMNw1yj d3rhtu66OqzMnKEWzINQt9oYv5Tcd3egCxAb4y0CgDo0hpvEdqNpcXD2HIHB7gvVyUR4 +l0YXuau0mHv0xWSNLLF2uhmV/fvbtfCqGOpfpqahoGzfYmhxdL0Qnvoykg8rwF7KScB XyP5+Ngpp7IpjUJZtCnYtai8CGBXirXzovnJyhNw2J5aBcZB1lun+syHpV2tBsRibylS 7Aew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=9ZY8AnVRqlaxNKg7qnrDwJ4JLJvEcFtMb6ZHM3dyyYI=; b=vMAHLkjB+EB+4uJs7MQS46iwZkDA0HMwezRdzUPS4UFibO4XKJjE3EMTva+beX13OX o21Hb+pOEpqf31rIymXZuZyxSBq7hj+P0UQERnMPfZkPOZjqzxiMFUAo8vNBV83zKCu/ TJxGJoHlAYeR7d71apFcJAOsws92Oit9/RkuTpBZzT78bW5A/kTN/K2isXVYTactPe0C h3Qcfvo0Nj8+/GNcODIYrvd+hNFHnBHiRKIALHu0btfCJ62OeHSjgNUwZ3Rx0Z4A7AH4 Vfn6cUqFBrvVJJqtEf5d8iDgCuXAY+R4IOPG15ncURNKGWlEUEJEcRjvT1Ynso/iQbLB TFvQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q11si14026913ejr.604.2021.03.16.08.12.24; Tue, 16 Mar 2021 08:12:49 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235530AbhCPIxH (ORCPT + 99 others); Tue, 16 Mar 2021 04:53:07 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:33872 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S235451AbhCPIwj (ORCPT ); Tue, 16 Mar 2021 04:52:39 -0400 X-UUID: 951bbb43011f4072815d6f907817e9e1-20210316 X-UUID: 951bbb43011f4072815d6f907817e9e1-20210316 Received: from mtkcas10.mediatek.inc [(172.21.101.39)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.14 Build 0819 with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1207799967; Tue, 16 Mar 2021 16:52:18 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs07n2.mediatek.inc (172.21.101.141) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 16 Mar 2021 16:52:17 +0800 Received: from localhost.localdomain (10.17.3.153) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 16 Mar 2021 16:52:17 +0800 From: To: Richard Weinberger CC: Matthias Brugger , , , , , , Guochun Mao Subject: [PATCH v1 1/1] ubifs: only check replay with inode type to judge if inode linked Date: Tue, 16 Mar 2021 16:52:14 +0800 Message-ID: <20210316085214.25024-2-guochun.mao@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20210316085214.25024-1-guochun.mao@mediatek.com> References: <20210316085214.25024-1-guochun.mao@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Guochun Mao 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. Signed-off-by: Guochun Mao --- fs/ubifs/replay.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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; } -- 2.18.0