From patchwork Fri Nov 17 19:50:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 10063545 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E6FA66023A for ; Fri, 17 Nov 2017 19:50:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D85A52A8CD for ; Fri, 17 Nov 2017 19:50:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CD2022A989; Fri, 17 Nov 2017 19:50:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A21222A8CD for ; Fri, 17 Nov 2017 19:50:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965161AbdKQTuu (ORCPT ); Fri, 17 Nov 2017 14:50:50 -0500 Received: from mail-qt0-f194.google.com ([209.85.216.194]:39601 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757279AbdKQTus (ORCPT ); Fri, 17 Nov 2017 14:50:48 -0500 Received: by mail-qt0-f194.google.com with SMTP id p44so8212319qtj.6 for ; Fri, 17 Nov 2017 11:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=smL5b3yNm6udj68TMrmD40jjnJISatIdBy1xvXbcTUs=; b=AK17VFO0ndVs2HQIqh52XeS2a+LA8DOzLxwVweBDHIGb3IKouaAkdwZLlA0qb4whS7 Sx2SzBaSQjbZGOS4WujSYyPzze5g5fztI77PkzvxETo822NgeF8fFzbrWF3RRjWX764v jvcwtZLgRb4aIcm78HLYx6TxPyQCM1UCnQlq/DlQ/rJTBMyY885CHTv0EFuET92udMEc nS+EyY1Gqfl3DtY2kOcgA2WWTI61SoxIkH/aVgyxUO5Gk2EdwE6SWtoZBPLB8okJ6baY 4fGykU0lYqv19eNZY5MgogmUVV9ri0vZ+UmkZARjrACRjOMlgLhPhvYGWTyCYXzpWZd6 djrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=smL5b3yNm6udj68TMrmD40jjnJISatIdBy1xvXbcTUs=; b=ZDmcDpbB9lITo2FqZPpnLdwVvhVSfhvkfuZEHAPCgnBh/dZi0IKAZ924OgXu5gPIKp m3NZIia7nM+mHm/ywAO3PVlVD7PtWOf8OOlBgX87u53cA12TMgQ8Ev4Ac4eFOnCEr6mG dShfwirNYwA8ptd53U3ZCI2s7/0jBFCzcwvz/RiqGbEyd+qWXENxGBni6o5QO6XRoglG NNapoPP67pwFZzHRJwTSI2ijdUNvYqXZ9c2rGBgt33vKZZHUC12OtKmLJvO7f/gNseEA EvXKq/9tvPAjqW5IXDNPLxXoMclYfWrBevzIhJyTM5GQuYCQqZKsoglpM16VRLzC5RPo PdkA== X-Gm-Message-State: AJaThX7sNNBkGigh8WNxaxIZqrd3/kOZzAz+jJzyPU8esgUq0dQS7rRY od0gTOHXYjcYJ/nFaWJx0VCMaxw0Kjw= X-Google-Smtp-Source: AGs4zMbn0RTf2eyzI7r3ERB8mDW4/X9W8bZUUGSG7Zb7Xlv6nhFQPCoL2iDbHYnowER6vGkLsMLrdQ== X-Received: by 10.200.37.107 with SMTP id 40mr10530663qtn.85.1510948247815; Fri, 17 Nov 2017 11:50:47 -0800 (PST) Received: from localhost (cpe-2606-A000-4381-1201-225-22FF-FEB3-E51A.dyn6.twc.com. [2606:a000:4381:1201:225:22ff:feb3:e51a]) by smtp.gmail.com with ESMTPSA id g32sm3263826qkh.74.2017.11.17.11.50.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 11:50:47 -0800 (PST) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Cc: Josef Bacik , stable@vger.kernel.org Subject: [PATCH] btrfs: clear space cache inode generation always Date: Fri, 17 Nov 2017 14:50:46 -0500 Message-Id: <1510948246-32434-1-git-send-email-josef@toxicpanda.com> X-Mailer: git-send-email 2.7.5 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Josef Bacik 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. Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik --- fs/btrfs/extent-tree.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index e2d7e86b51d1..67b26b209e23 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -3526,13 +3526,6 @@ static int cache_save_setup(struct btrfs_block_group_cache *block_group, 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 @@ -3556,6 +3549,13 @@ static int cache_save_setup(struct btrfs_block_group_cache *block_group, } 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(fs_info, &fs_info->global_block_rsv);