Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp690627ybz; Fri, 1 May 2020 06:53:54 -0700 (PDT) X-Google-Smtp-Source: APiQypJtg8bvjWUCAXZGcTi7Ffm8XSUbTuXcBVhFeCHW0ipF3gTTtIw+iC+C9GU+UCsc1RHTB9uQ X-Received: by 2002:a05:6402:b4c:: with SMTP id bx12mr3714862edb.247.1588341233987; Fri, 01 May 2020 06:53:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588341233; cv=none; d=google.com; s=arc-20160816; b=DINsVgIr2nnRLCVJ897qAhipP8qa9DVLXTaVW5uIa6SYUZD4yYuG9YP2W3AIg+y9/M aXUJoC5nvOAv8WXhhrqld/G5pPZEktVTj5NwHWqUmQEg2nJtwWOCCzRUmRhq3jk92JQ1 aHc7DqU6ZGc2coLg2H+mJDtnrJnNxZ3jcUQcvdMkyf0TKCS0IdNPmSDlwpH7ZYYECsew WcdeeKlA7otUAPmxob68LFNbohdZQHKHDpG1KTYWJ7uDuOBdqa9cVJWvx4uDDtMStuuo T1P5m3IaDlg/I59CnVRpXwYH0xSx+bjGi7gCgUz5Np0n9NRtbsiVAZX+qC4zWoim/f/g UFFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=K4AoYtKMM2g+g40eppEIQC8UiEOeBaQgGeVbgGmj8xo=; b=RETQU14Es37dYZYecvkiz3U/gcq1r5qCUGI8b3vc3gD0wtEqdZljCjTfxiKD5dkVe/ DL0g9kzNqs6PQd5N4oMWnuKznMS6Y6q2ffAS0v5D6luxabNhgEv+MrNDlPJL5QiXHEoQ 561d9dW7MReg73F2+hzvcEZ6DNMcJFR59FtKB89oT/oa5YClTPOCdXE/VOkppLndJwrY 8fWndVoWY6JgrAzVAR1URE6fI8HTD7e5ir4j7sp9aHVdK8qssYREO+u7+dF296/Ryukc MnYBn+jSRwevobyk8bPEwmltmD5FogtLJBg7k2B9rtu0muqVRXI4ex3NCKBz09tuhYnI hUnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=0f+vgwri; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f3si1746579edy.68.2020.05.01.06.53.30; Fri, 01 May 2020 06:53:53 -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=@kernel.org header.s=default header.b=0f+vgwri; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731878AbgEANtx (ORCPT + 99 others); Fri, 1 May 2020 09:49:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:41018 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730659AbgEANku (ORCPT ); Fri, 1 May 2020 09:40:50 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 823AC205C9; Fri, 1 May 2020 13:40:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588340450; bh=d9WCOVPH7L+/dPvkYP6Uk/9VEzZL2uz/ct95MRypraM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0f+vgwrix9fzqc8k7+usH5ovNgz9AabKuidbj+t+GvK74YpjHp0+GR3nwA7wscOD3 LfdFMJkzFXK65+fwvSWjf8AlufSQMLR7unGRNO++vGvvPCT0RxE38ZBVeGpSCNQbjE SNPMNg3MOiFp2cBDFlK3gVdwIGHTxqXy428SyTaI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Theodore Tso , Sasha Levin Subject: [PATCH 5.4 72/83] ext4: increase wait time needed before reuse of deleted inode numbers Date: Fri, 1 May 2020 15:23:51 +0200 Message-Id: <20200501131541.643071096@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200501131524.004332640@linuxfoundation.org> References: <20200501131524.004332640@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Theodore Ts'o [ Upstream commit a17a9d935dc4a50acefaf319d58030f1da7f115a ] Current wait times have proven to be too short to protect against inode reuses that lead to metadata inconsistencies. Now that we will retry the inode allocation if we can't find any recently deleted inodes, it's a lot safer to increase the recently deleted time from 5 seconds to a minute. Link: https://lore.kernel.org/r/20200414023925.273867-1-tytso@mit.edu Google-Bug-Id: 36602237 Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin --- fs/ext4/ialloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c index a6288730210e8..64b6549dd9016 100644 --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -660,7 +660,7 @@ static int find_group_other(struct super_block *sb, struct inode *parent, * block has been written back to disk. (Yes, these values are * somewhat arbitrary...) */ -#define RECENTCY_MIN 5 +#define RECENTCY_MIN 60 #define RECENTCY_DIRTY 300 static int recently_deleted(struct super_block *sb, ext4_group_t group, int ino) -- 2.20.1