From patchwork Fri May 11 00:11:15 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 10392601 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 8CBD0601A0 for ; Fri, 11 May 2018 00:11:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 82EBF28D68 for ; Fri, 11 May 2018 00:11:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7774028D6B; Fri, 11 May 2018 00:11:43 +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=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, 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 1E46328D68 for ; Fri, 11 May 2018 00:11:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751695AbeEKALk (ORCPT ); Thu, 10 May 2018 20:11:40 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:34601 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751462AbeEKALi (ORCPT ); Thu, 10 May 2018 20:11:38 -0400 Received: by mail-pl0-f68.google.com with SMTP id ay10-v6so2225341plb.1 for ; Thu, 10 May 2018 17:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=njkw9361SsO0B7P4s8Oeds4UZrfOpbQVQovWH0XqLmE=; b=jCJ98oOCPo4TQJtkFhWwvb20J7ic5KPX0ua7VWDE9xOrEE+2IVcz0hecE9DDNsLSPg ghY1HS8jenPRgxi6LAHo474B3m+Hifes3kqFoAR+MoGOFmZaWqoS1jT/rqlAmk1coJbj 3J9OC5dnC+RwoCBNTw1ChKDTk+TixNVv0T0Af+I5HFaG5BVS/+JPJ8sQxY++JLM9rLdS Bjhhhp8Kr++CprDV1sWuecJWpi0jsc5gAqfIarW97hNCX7WerTcfiSzSi6jmeNgIi7lu TJWxnMNgnSrGtgqL2vWcyTOS3mTBgPu76ahahs3F0qDIN9FgSUKtPfa34HdSDFnuXUf8 hzBw== 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:in-reply-to :references:in-reply-to:references; bh=njkw9361SsO0B7P4s8Oeds4UZrfOpbQVQovWH0XqLmE=; b=mzSgQ9SxJvf3YR1crpd5G81vaRhRSyGH8xwOTUpK1HqAZQGIMm5phMIeisIS+4ScG5 btdm30IpqDrXJNgL1hRxj5A51aD5rGt7vdLfcE0UUfOJHypQIwvYn7/fsUorkgfGAx1J 0gFKGydhS4RwsdpcruhJQr3gMV7RFFYZE33qkuNKX/RFuohoEjJM0CEa94NDnJ3RJjsi +TFxTuSVgMr9GmemIu6j7/Nw2f9plsz5e0F8PFnkIY/d1zP1mSBalK2jJa8lTP7eatG5 s62frfJ4Z1KfZRpf3e9AsR6CGnKXUYvyZ5eUL3ge/nw9fOvofEjEiMbqxXT77bqq7W5d +tIQ== X-Gm-Message-State: ALKqPwdKo+XF/sqtmEYtKh6U0xwekx4P90+FpHVScYvW3SyEbQDfvJbl nZ1R4v2Q7/2qXlpYFwUmUy8K688jGD4= X-Google-Smtp-Source: AB8JxZrfDvLi10nVkpBkD3lgRyPNQYsvSm/fLlSD1fr4K4DGASA3xZdvcR7dye3nDHq5bC8vm8GU/Q== X-Received: by 2002:a17:902:aa98:: with SMTP id d24-v6mr3235736plr.185.1525997497738; Thu, 10 May 2018 17:11:37 -0700 (PDT) Received: from vader.thefacebook.com ([2620:10d:c090:200::4:32a8]) by smtp.gmail.com with ESMTPSA id x84-v6sm4699038pfi.160.2018.05.10.17.11.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 17:11:37 -0700 (PDT) From: Omar Sandoval To: linux-btrfs@vger.kernel.org Cc: kernel-team@fb.com, Chris Mason , Josef Bacik Subject: [PATCH v2 05/12] Btrfs: don't release reserve or decrement orphan count if orphan item already existed Date: Thu, 10 May 2018 17:11:15 -0700 Message-Id: X-Mailer: git-send-email 2.17.0 In-Reply-To: References: In-Reply-To: References: 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: Omar Sandoval Currently, if btrfs_insert_orphan_item() fails, we release the reserved space and decrement root->orphan_inodes. However, we also ignore -EEXIST errors, so we still want the space reservation for when we delete the item, and we still need to count the orphan because we're still going to decrement root->orphan_inodes from btrfs_orphan_del() later. Fixes: 4ef31a45a009 ("Btrfs: fix the error handling wrt orphan items") Reviewed-by: Nikolay Borisov Signed-off-by: Omar Sandoval --- fs/btrfs/inode.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 1460823951d7..e77df96de642 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3408,7 +3408,7 @@ int btrfs_orphan_add(struct btrfs_trans_handle *trans, /* insert an orphan item to track this unlinked file */ if (insert) { ret = btrfs_insert_orphan_item(trans, root, btrfs_ino(inode)); - if (ret) { + if (ret && ret != -EEXIST) { if (reserve) { clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); @@ -3420,14 +3420,11 @@ int btrfs_orphan_add(struct btrfs_trans_handle *trans, * decrease ->orphan_inodes after everything is done. */ atomic_dec(&root->orphan_inodes); - if (ret != -EEXIST) { - clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, - &inode->runtime_flags); - btrfs_abort_transaction(trans, ret); - return ret; - } + clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, + &inode->runtime_flags); + btrfs_abort_transaction(trans, ret); + return ret; } - ret = 0; } return 0;