Received: by 10.223.185.116 with SMTP id b49csp6322924wrg; Wed, 28 Feb 2018 07:33:42 -0800 (PST) X-Google-Smtp-Source: AH8x2242POjK62XPjIDa2YzNADyseNFThTBE/ZwpL98vhIn+AlCUjupCCDNqCVbI/07Wc52FFIVC X-Received: by 2002:a17:902:aa87:: with SMTP id d7-v6mr18262043plr.237.1519832022823; Wed, 28 Feb 2018 07:33:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519832022; cv=none; d=google.com; s=arc-20160816; b=ioQkmxm5hiAZgAEXC3f9PG2NVzhT1PPlu8xu/RkvdrTgpPUOpRBNkBAJ97T3r42H5/ EzTUZiShFp6NrWI8jPr8lGY+G9Zo3mcu4Mzu3VetPg7/qJRLPoD1pVQbDezQd4t0WBdy Qc2RWGZuLro7CZSgtvh5PR7aHyc3cW3t5LqygF8NEuWg79i+p8Q2S3HxkLBc0nmyFTTp hWnAi/JYd7oUcRkfJoxpwTavqYzf8jvqigoLyPHusFOfNGp6AxOTecVCPvtzUVkhoiDB LetEaE4FhMEkGp1munsfRmKgm/6lDul1FG+j/Jdw93QUfBXLePuLY41vKdatNbfVyh7E i8HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=RdnWbvP8LQwx1JsoW9IDcBfPWBUqypk1lxPyIkfiSPo=; b=aDjabe9BNg5+sGDcxnUAbdSpNj2M3V3McSXu2zM2jWhTmPsWWHY64bZsvxGH78L49p dJshvnxyKMBRuIC4byAT6pZARBzclk+cw9qSrn8nt4DxgvhYu+kLV77OtZo+tByrEUZV 3gIwgeQvJWr9yg5l2QmW6pvrhv8edlwPQeO2mE+pPcYKJOTDC08reb7T+DvZQht1iYp7 LbCKuDuo+YPU4X2Q32ibMAQOY3GukBnMqyrrEqWb7IqesVmWoLSLD9QB6xWeLG7CO+jX rnUEAgkUEcqb1J8OUc7MfwVEQCYcmqTGJcaOt/UZZdIyw4ac+tiCE3ptLeMZ5nX2163v S1kQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p1si1138975pgc.280.2018.02.28.07.33.27; Wed, 28 Feb 2018 07:33:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933154AbeB1Pc2 (ORCPT + 99 others); Wed, 28 Feb 2018 10:32:28 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:33257 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752790AbeB1PWi (ORCPT ); Wed, 28 Feb 2018 10:22:38 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yd-0006XR-U5; Wed, 28 Feb 2018 15:22:16 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yc-0008ML-So; Wed, 28 Feb 2018 15:22:14 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "David Sterba" , "Josef Bacik" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 007/254] btrfs: clear space cache inode generation always In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Josef Bacik commit 8e138e0d92c6c9d3d481674fb14e3439b495be37 upstream. We discovered a box that had double allocations, and suspected the space cache may be to blame. While auditing the write out path I noticed that if we've already setup the space cache we will just carry on. This means that any error we hit after cache_save_setup before we go to actually write the cache out we won't reset the inode generation, so whatever was already written will be considered correct, except it'll be stale. Fix this by _always_ resetting the generation on the block group inode, this way we only ever have valid or invalid cache. With this patch I was no longer able to reproduce cache corruption with dm-log-writes and my bpf error injection tool. Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Ben Hutchings --- fs/btrfs/extent-tree.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -3236,13 +3236,6 @@ again: goto again; } - /* We've already setup this transaction, go ahead and exit */ - if (block_group->cache_generation == trans->transid && - i_size_read(inode)) { - dcs = BTRFS_DC_SETUP; - goto out_put; - } - /* * We want to set the generation to 0, that way if anything goes wrong * from here on out we know not to trust this cache when we load up next @@ -3252,6 +3245,13 @@ again: ret = btrfs_update_inode(trans, root, inode); WARN_ON(ret); + /* We've already setup this transaction, go ahead and exit */ + if (block_group->cache_generation == trans->transid && + i_size_read(inode)) { + dcs = BTRFS_DC_SETUP; + goto out_put; + } + if (i_size_read(inode) > 0) { ret = btrfs_check_trunc_cache_free_space(root, &root->fs_info->global_block_rsv);