Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Johannes Thumshirn <jthumshirn@suse.de>
To: David Sterba <dsterba@suse.com>
Cc: Linux BTRFS Mailinglist <linux-btrfs@vger.kernel.org>,
	Johannes Thumshirn <jthumshirn@suse.de>
Subject: [PATCH] btrfs: remove unneeded check for btrfs_free_space_info in insert_into_bitmap()
Date: Tue,  5 Nov 2019 14:51:27 +0100	[thread overview]
Message-ID: <20191105135127.17357-1-jthumshirn@suse.de> (raw)

The only caller for insert_into_bitmap() is __btrfs_add_free_space() and
it takes care that the btrfs_free_space_info pointer passed to
insert_into_bitmap() is allocated.

Inside insert_into_bitmap() we're not freeing or NULLing this pointer
anywhere, so checking if it is pre-allocated inside 'new_bitmap' label is
pointless, so remove this check.

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
---
 fs/btrfs/free-space-cache.c | 23 +++++------------------
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 279c41c4ba50..02f680be8999 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -2121,7 +2121,7 @@ static int insert_into_bitmap(struct btrfs_free_space_ctl *ctl,
 		goto again;
 
 new_bitmap:
-	if (info && info->bitmap) {
+	if (info->bitmap) {
 		add_new_bitmap(ctl, info, offset);
 		added = 1;
 		info = NULL;
@@ -2129,17 +2129,6 @@ static int insert_into_bitmap(struct btrfs_free_space_ctl *ctl,
 	} else {
 		spin_unlock(&ctl->tree_lock);
 
-		/* no pre-allocated info, allocate a new one */
-		if (!info) {
-			info = kmem_cache_zalloc(btrfs_free_space_cachep,
-						 GFP_NOFS);
-			if (!info) {
-				spin_lock(&ctl->tree_lock);
-				ret = -ENOMEM;
-				goto out;
-			}
-		}
-
 		/* allocate the bitmap */
 		info->bitmap = kmem_cache_zalloc(btrfs_free_space_bitmap_cachep,
 						 GFP_NOFS);
@@ -2152,12 +2141,10 @@ static int insert_into_bitmap(struct btrfs_free_space_ctl *ctl,
 	}
 
 out:
-	if (info) {
-		if (info->bitmap)
-			kmem_cache_free(btrfs_free_space_bitmap_cachep,
-					info->bitmap);
-		kmem_cache_free(btrfs_free_space_cachep, info);
-	}
+	if (info->bitmap)
+		kmem_cache_free(btrfs_free_space_bitmap_cachep,
+				info->bitmap);
+	kmem_cache_free(btrfs_free_space_cachep, info);
 
 	return ret;
 }
-- 
2.16.4


             reply	other threads:[~2019-11-05 13:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 13:51 Johannes Thumshirn [this message]
2019-11-05 17:08 ` [PATCH] btrfs: remove unneeded check for btrfs_free_space_info in insert_into_bitmap() David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191105135127.17357-1-jthumshirn@suse.de \
    --to=jthumshirn@suse.de \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox