Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2548572pxj; Mon, 10 May 2021 05:41:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwm2qJNYpdoCnJl1g0j87BPu0RwhGmaUz9OMH37EhjMjaK1Kj+VZkp5hNGkB018KJer2IE4 X-Received: by 2002:a17:906:11d5:: with SMTP id o21mr21595930eja.176.1620650500111; Mon, 10 May 2021 05:41:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620650500; cv=none; d=google.com; s=arc-20160816; b=NsC+V24bfdSsBckz3lbixaJpqzZxwY/oJz86toviwUwTO8IYEfQkD99AFiNdbCfacT KvN2EI0xblM7XSd+mb6j6YqWd7WN67G1J3G8YhbIeNU0ATeXD8uT2zp7ISgLKB3FyHmZ BM44BqiobpLils7rSWAKEzLiJDWwPKlrQFY5il2zBuiMyv5hZP0iVmLXhmN379jByRhd EIEEZAmCm7hnkjP8EfCwKTL5WwEdNPC8F2rkjMKOxAuAnR5nhz6V3gs3BEzB7PPIi/pj S5Oy/EPbS6FsasXr3t924blekNVCfHm4T/hlCcgRckrceWK0wmoHL8irt31f5ucVEZMH envg== 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=kEmw3zGJ/4n4JCspico3mhB0NKC1FnOx6bpiMFRd9yaO9o1UojZzbxDDvaHoEFucSa v/xJxFu3L3Wl9NckWWr7yWd1gIhxmLQ3QufRlcVBsEXcRoz2xUE0OmfbQ3nGujYOfmYi X7YsPCTDSxLCF2P0R3aa0WheeOklLJS4PdlVWJ7idlruQQUa09Q4/mUlctqgxJDb7z2J I9ACARMbHtBvJNumK96litw92YbQ7XHPQIlnm/h4iVZ37bEcfeFlxQJnKDz2S7tfLnQL x71ugJjJQQ/A1vR4E692Dbua+xdgs0aJTT9r6AUjWqjIYKt7K3KndyNACcgeg+kglDSV q6eA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RYdZbDOK; 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 v29si12729093eda.308.2021.05.10.05.41.16; Mon, 10 May 2021 05:41:40 -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=RYdZbDOK; 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 S1346975AbhEJMdF (ORCPT + 99 others); Mon, 10 May 2021 08:33:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:46846 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231584AbhEJLLu (ORCPT ); Mon, 10 May 2021 07:11:50 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C08D36191C; Mon, 10 May 2021 11:09:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620644954; bh=j+yJxaDaNg+0dsAfuh4blpsx95zm7XMjaysqroZ6ZpI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RYdZbDOKNwwK44YFK68M76yfgRSFSWV3ttVjTNw+BY8ecJ/v1W+hI4hLeGhAs5J7i g1GdSPwQORJDfUz/KQzMFJNlh7yK+e/pEkMjeCubQy/y76Jz/wsH9hU2hAPd0Wobqi U861mgGUiX+HJrVSjJuZbZRp7c0YQbG8Name4FqQ= 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.12 291/384] ubifs: Only check replay with inode type to judge if inode linked Date: Mon, 10 May 2021 12:21:20 +0200 Message-Id: <20210510102024.409174287@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210510102014.849075526@linuxfoundation.org> References: <20210510102014.849075526@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; }