Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3316849imu; Sun, 11 Nov 2018 12:13:30 -0800 (PST) X-Google-Smtp-Source: AJdET5f5B4XCd6h9f/UOPEdxzeIF3lgMEqSdevK2V+8MJyOgu7PsxIddV0QAvSPQXKRw+z+0ZqFg X-Received: by 2002:a17:902:66e5:: with SMTP id e92-v6mr16862718plk.92.1541967210603; Sun, 11 Nov 2018 12:13:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541967210; cv=none; d=google.com; s=arc-20160816; b=SCaUW7oNZdrNPdO+rnkFdQ0igsrqGEowDsbvHLmPO/ediR8dy3ZMOc8JWxNkr7Owfx XCX9gBRngxIQbHgTptmGFKOLOQbLbwSSbZNo5vu8SfpDyPaFvSpflBRtwd9IsilzFI3I 2u0Ye5Ywc7g9xHCyDHgMbYBp0Hu521tcZfEl3KWPGwAkHTvfhuwcYM0OiNy5OlPsTjWs rKP3kNw+NTTiL4XI4y6f12U+yt23FpnS5/HsamB6a12Aen/1uYMEkOGWYEe4MBAGghrQ N4XA1qLEaqbt2uAXymCFRuQxpMcVNwwAEvqzv5nDqrC4fetzd4OvRNVRmYtqEj9eKn6U Z7DQ== 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; bh=HLHbNItOnFvJgRGhRrwk8cap8s44NFTUJGrpygEwauo=; b=JX9ddbLhCtSDIiuOpnvx2qk3wsHy9iEO9Kzn2TVIiE7naIRfBw1dBTOASp2wT0cXEh WQbzuYzgPEh52VE/H2M6vgAL7AEv0EMF7XqzaZULzcboHtcJskgahFDxbUaYAt4HdGfl V2gDUrOxTQrmEjAhXZqbBQV3X5+1IMy2dhCvpVts1A0FTbAP3ZnYHA0Z/7yr5jzufLSy b5Tl70AFjH5LhksbHxcLDhN7d84xKFPlBIj8w1YtlYM1f1rn1jcmwcPdSVYaLsR0TDZU FJXj+bXSburcYOrUF7PkuCBr+xR5mWhQZ+q4Sf6szV7ItsGCtBMHkwLVctjtnmZ3tMR0 DX/Q== 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 w65-v6si17158159pfd.55.2018.11.11.12.13.15; Sun, 11 Nov 2018 12:13:30 -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 S1731666AbeKLGAo (ORCPT + 99 others); Mon, 12 Nov 2018 01:00:44 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:52460 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731019AbeKLGAn (ORCPT ); Mon, 12 Nov 2018 01:00:43 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvt6-0000lJ-1L; Sun, 11 Nov 2018 19:59:16 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsQ-0001Tz-EQ; Sun, 11 Nov 2018 19:58:34 +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, "Josef Bacik" , "David Sterba" , "Omar Sandoval" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 090/366] Btrfs: don't return ino to ino cache if inode item removal fails In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 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.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Omar Sandoval commit c08db7d8d295a4f3a10faaca376de011afff7950 upstream. In btrfs_evict_inode(), if btrfs_truncate_inode_items() fails, the inode item will still be in the tree but we still return the ino to the ino cache. That will blow up later when someone tries to allocate that ino, so don't return it to the cache. Fixes: 581bb050941b ("Btrfs: Cache free inode numbers in memory") Reviewed-by: Josef Bacik Signed-off-by: Omar Sandoval Signed-off-by: David Sterba [bwh: Backported to 3.16: - Pass inode, not btrfs_inode, to btrfs_orphan_del() - Pass btrfs_root, not btrfs_fs_info, to btrfs_free_block_rsv() - Adjust context] Signed-off-by: Ben Hutchings --- fs/btrfs/inode.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -4908,13 +4908,18 @@ void btrfs_evict_inode(struct inode *ino trans->block_rsv = rsv; ret = btrfs_truncate_inode_items(trans, root, inode, 0, 0); - if (ret != -ENOSPC) + if (ret) { + trans->block_rsv = &root->fs_info->trans_block_rsv; + btrfs_end_transaction(trans, root); + btrfs_btree_balance_dirty(root); + if (ret != -ENOSPC) { + btrfs_orphan_del(NULL, inode); + btrfs_free_block_rsv(root, rsv); + goto no_delete; + } + } else { break; - - trans->block_rsv = &root->fs_info->trans_block_rsv; - btrfs_end_transaction(trans, root); - trans = NULL; - btrfs_btree_balance_dirty(root); + } } btrfs_free_block_rsv(root, rsv); @@ -4923,12 +4928,8 @@ void btrfs_evict_inode(struct inode *ino * Errors here aren't a big deal, it just means we leave orphan items * in the tree. They will be cleaned up on the next mount. */ - if (ret == 0) { - trans->block_rsv = root->orphan_block_rsv; - btrfs_orphan_del(trans, inode); - } else { - btrfs_orphan_del(NULL, inode); - } + trans->block_rsv = root->orphan_block_rsv; + btrfs_orphan_del(trans, inode); trans->block_rsv = &root->fs_info->trans_block_rsv; if (!(root == root->fs_info->tree_root ||