Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2466324pxj; Mon, 10 May 2021 03:47:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyQVap1F6bBNgJjeJikBy11Q9/SI/xJpltkePxvUi+/FZns8J75W6gy2BabFDidiKYLNtFT X-Received: by 2002:a17:906:d1d2:: with SMTP id bs18mr2935122ejb.56.1620643630441; Mon, 10 May 2021 03:47:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620643630; cv=none; d=google.com; s=arc-20160816; b=aNtob+tx0kGOsV0PnjspoJgDgwNKjD0/arZzHI9ZVA2FpApWB4An5Tfkc3wuSXNl8M 2qkVDEujjPIDmic21RZOMSX1P6fMNeVz9jcxfxGPHOciO4wQZSfCb+SxdNSFwf9Tycv6 5MzkBFmucvjev/h4XGkxYspOBEg7GxFRHe0H9C5FJihqeoLJdAAin52/okUM5/8HzdnV 0EnjdLUHKwEIjgSFJmE5Zyg5YyKhlHEgKo4d34Wwn7LtYwHF2KiH0PMX7yXI5sBfchWs uABAR/T8oaz5DMHg6oQha0Nx15OLvr9sYVTshHPduTpWTD6VIwbli9D1ahXE7pX32fec B6dw== 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=CnsDBmNxi63R452xZgTtcZjDVu9OvRb639E7AOvPsDCZ8TVYQoHeKQoQMdhyA5YCq2 iD17U8Zip8YJJnWUhl/k9uLSAFtW7MERGixjeOCz9BAk3nVntEj1mKuH1CXYg2OLCRX1 k14R6UzaINeNQ95+iur7M8wvhvMbBBgJkUlzZZzUTxDNYGPpvUtNvawBM2fSTB+PP9q8 cVjoh5gZQhaJXYHw6q5wP+5P5P1TVHhiORWld7ipVy5eXke+aFJmO7Dwepn4Rw12FwSh peJbdYoIJNmCqmpU4A235r4ol6QlVWkpK7DuxiA/vZztNSXurGY7kavnVMf2F9ntbWCi PhTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=fuXQJJAX; 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 y22si12721427edr.245.2021.05.10.03.46.46; Mon, 10 May 2021 03:47:10 -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=fuXQJJAX; 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 S232799AbhEJKog (ORCPT + 99 others); Mon, 10 May 2021 06:44:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:41148 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232008AbhEJKf5 (ORCPT ); Mon, 10 May 2021 06:35:57 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 260706193D; Mon, 10 May 2021 10:29:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620642546; bh=j+yJxaDaNg+0dsAfuh4blpsx95zm7XMjaysqroZ6ZpI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fuXQJJAXhEmv1MBIkYtnB0yI0IONwl5tGIR7FKLcGAlZy2HBGigzc/7twQDV6l9iI SYg+pE+NJomf9MjtJ81gdycOF4L3QOlgapjChfe+yKXWPTxVM/ObcC6jj3JprZufnX 7rpLx7+lfGC3+6Hpl4ewU43Ckd6n0Y2/BKnYHDPo= 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.4 139/184] ubifs: Only check replay with inode type to judge if inode linked Date: Mon, 10 May 2021 12:20:33 +0200 Message-Id: <20210510101954.704669590@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210510101950.200777181@linuxfoundation.org> References: <20210510101950.200777181@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; }