Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2509558pxj; Mon, 10 May 2021 04:51:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyXUPXH46+v5dxRku1JM5QI/J0HmWT/prm2inIoMGLq8PRHaHASdNWHIur1IbqGd8CqXeb7 X-Received: by 2002:a02:a88f:: with SMTP id l15mr21805368jam.86.1620647476928; Mon, 10 May 2021 04:51:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620647476; cv=none; d=google.com; s=arc-20160816; b=pq55QP7Y1apqHW6PvXKxaYIuZxjxmkse9K2tMJk3CXRBp5i92MNM5Hg8PQPCZbuU4P l7+Mtm5Yt7E6z+TCKpQWXFnCIxIAdJxPbk4B9GGSmFQ8gAB3FLfUibFr91+4si9EFccS qXPg2iGI6sA168cWZj5VdTzzqCmF3MQoZqjV90A78Mzyi8HxHUJnmVRTy/QNunUgzrZY foKKkv5t4nVE2wTX6tuhP22uWy6dg30z1X0Jy+M2bRlfdULDpct0vdS2X8rVz/Crgrz2 hMGe4Y3EAcoJH3cgeNXaS/OvMH6hpho2MVuJxL3NJksrNrbAan72bKmh5gXS2PuHLyuu 9xfw== 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=wLrUSK1FXfVHsovXbhxnwA0BYHhQ8fxceET8oRB2GopoF6Xx/7XlODSkRlBYFGdX0Z vykYEVL9taT2SPsTd2OydoAyNuzrgC4wrdg8QB3tLYfCkDLlf/dhNLu7JTqFZ2y95z22 J2EiVzcxg5SgnMKh9JK3YHNa/utRDPqPrx2j8QTrhcOh+LIBQ8aNW3fC3u40dYhVxva7 uL1RSucqAKKR+lkS2OzWvqlXUVbbL1rDh/fsufWRV/PGPcobB5JTcDUXt4nDOZR6wza+ io7fYUV9b7Iiv+XvIq3ht7ZXgM8icrwPON+HYqEmq/YlTw4B/t0lYuUdt6JrDGtVPvbt n+vw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=GNyv+DC0; 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 j1si16372575jat.46.2021.05.10.04.51.03; Mon, 10 May 2021 04:51:16 -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=GNyv+DC0; 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 S243245AbhEJLsV (ORCPT + 99 others); Mon, 10 May 2021 07:48:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:36600 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233645AbhEJLBs (ORCPT ); Mon, 10 May 2021 07:01:48 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 53A9C61C55; Mon, 10 May 2021 10:53:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620644025; bh=j+yJxaDaNg+0dsAfuh4blpsx95zm7XMjaysqroZ6ZpI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GNyv+DC0WQl5BGw9htDpPozkHPOb13t9NLiXOu+1Duc2L00Jt/q8D7U4d5JIspfJW dWL/FWJFE0IDrbrrSa12gKQIIMFH7HFQs7waYEp4Obn47O9AyrJyQlB2cEsQ8NnApm 6LDu9aQ6M4O0f8WQ+0VqH2nMYkN1wPopVwLLJrGE= 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.11 258/342] ubifs: Only check replay with inode type to judge if inode linked Date: Mon, 10 May 2021 12:20:48 +0200 Message-Id: <20210510102018.622052163@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210510102010.096403571@linuxfoundation.org> References: <20210510102010.096403571@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; }