Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2490209pxj; Mon, 10 May 2021 04:21:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwaYLRwLwxveF58lRa47z1+KbXjE2xGk0VvoJnYui3sSMAlRYJ3d5NtfmDgOEnl1w7YegIZ X-Received: by 2002:a17:906:e206:: with SMTP id gf6mr24557948ejb.434.1620645701601; Mon, 10 May 2021 04:21:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620645701; cv=none; d=google.com; s=arc-20160816; b=VEx4VWz9KWg7a3sDx9LcduSqzY/HyIhO0P5dTQTHg/4dWwoMHSV5yvD+BAGQvlXSRL IraVagVgGiklXrI4DWkmNSSVvUK0TWvBa+UHydbVVcwJcBkYZxNhXcBabux2aAZvtP86 uW2OFKD8un4YBYsl83GxEtk7YX/85zYUGmC63S96kSYWZZZo5Mx9Ab5NcKjTN35+8JuL Vr6WLt37WKXshDSlzrjpO607B5eyWGv6yzjwMnNRPGbwcnox00l7YrhsQ3TT6zYCwdcV fqCRdcE8tqfO2yz64zH+HKHHS7n/cfX1rFRxsBlYP7LrRJTQ8wttvALkTw3m1UXIPXRk 0XYw== 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=jLi4+umyTsl7F7LSSowYkWzPNQyqnRTkUnPG482zHAw=; b=X64lMFUQtqVrBfV9ocA0B0ecrFRGQ/rNYIB0/hAOHouFfvgXmpoRC90knNBefgC+/W yGMNZeDw0DdY3YBwJbCu4KGknmyc/ijihn3OI1Rtvn4hTrRN3tuLNxQsGNIY8rauuAMD jX7g1h3968Nc0Zja7Kp0xAYJKNRMWssYx7EOMynbH2TsOetv8xyFsb4SQ7GsaKMutQ9y tz8JpDqLGa+wpgUA4p+P1M+f279Cr59kSLQdotME4uPaXdFCTTQBE9mLXptYlYx/WRYa WrTWmBwdZYJimBM5fR7czih4KK7C3PqW2EZSsU8IAx4AOZGu6SRn/6WkR+X9U2XcUqT/ Dkig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=jkXipbe9; 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 d16si12621786edx.417.2021.05.10.04.21.18; Mon, 10 May 2021 04:21:41 -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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=jkXipbe9; 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 S237760AbhEJLQF (ORCPT + 99 others); Mon, 10 May 2021 07:16:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:41986 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232734AbhEJKuo (ORCPT ); Mon, 10 May 2021 06:50:44 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E11A46195E; Mon, 10 May 2021 10:40:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620643224; bh=j+yJxaDaNg+0dsAfuh4blpsx95zm7XMjaysqroZ6ZpI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jkXipbe9nzmOxV0ATMSB9UM6u+W6lZG+re74GQuZJBr7fHtir7NqpwgSa7CUlPG2s fKX5NI0wF6mky5qh4NQ2AUqFpTCZoooBYEnG2XNb0RBAOH2GJJt82awbnxixfEi09u QPZsZ+ZeNc7XKxlmbUwtIy3EOhwmdG95GIoPiMrI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guochun Mao , Richard Weinberger Subject: [PATCH 5.10 227/299] ubifs: Only check replay with inode type to judge if inode linked Date: Mon, 10 May 2021 12:20:24 +0200 Message-Id: <20210510102012.449612872@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210510102004.821838356@linuxfoundation.org> References: <20210510102004.821838356@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: Guochun Mao commit 3e903315790baf4a966436e7f32e9c97864570ac upstream. 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 Signed-off-by: Greg Kroah-Hartman --- fs/ubifs/replay.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/ubifs/replay.c +++ b/fs/ubifs/replay.c @@ -223,7 +223,8 @@ static bool inode_still_linked(struct ub */ 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; }