All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: Btrfs Development List <linux-btrfs@vger.kernel.org>
Subject: [patch v2 7/9] btrfs: Make pin_down_extent return void
Date: Mon, 15 Aug 2011 15:50:49 -0400	[thread overview]
Message-ID: <20110815195232.912795302@suse.com> (raw)
In-Reply-To: 20110815195042.559654068@suse.com

 pin_down_extent performs some operations which can't fail and then calls
 set_extent_dirty, which has two failure cases via set_extent_bit:
 1) Return -EEXIST if exclusive bits are set
    - Since it doesn't use any exclusive bits, this failure case can't
       occur.
 2) Return -ENOMEM if memory can't be allocated
    - Since it's called with gfp_flags & __GFP_NOFAIL, this failure case
      can't occur.

 With no failure cases, it can return void.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
---
 fs/btrfs/extent-tree.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4175,9 +4175,9 @@ static u64 first_logical_byte(struct btr
 	return bytenr;
 }
 
-static int pin_down_extent(struct btrfs_root *root,
-			   struct btrfs_block_group_cache *cache,
-			   u64 bytenr, u64 num_bytes, int reserved)
+static void pin_down_extent(struct btrfs_root *root,
+			    struct btrfs_block_group_cache *cache,
+			    u64 bytenr, u64 num_bytes, int reserved)
 {
 	spin_lock(&cache->space_info->lock);
 	spin_lock(&cache->lock);
@@ -4194,7 +4194,6 @@ static int pin_down_extent(struct btrfs_
 	/* __GFP_NOFAIL means it can't return -ENOMEM */
 	set_extent_dirty(root->fs_info->pinned_extents, bytenr,
 			 bytenr + num_bytes - 1, GFP_NOFS | __GFP_NOFAIL);
-	return 0;
 }
 
 /*



  parent reply	other threads:[~2011-08-15 19:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-15 19:50 [patch v2 0/9] btrfs: More error handling patches Jeff Mahoney
2011-08-15 19:50 ` [patch v2 1/9] btrfs: Add btrfs_panic() Jeff Mahoney
2011-08-15 19:50 ` [patch v2 2/9] btrfs: Catch locking failures in {set,clear}_extent_bit Jeff Mahoney
2011-08-15 19:50 ` [patch v2 3/9] btrfs: Push up set_extent_bit errors to callers Jeff Mahoney
2011-08-15 19:50 ` [patch v2 4/9] btrfs: Push up lock_extent " Jeff Mahoney
2011-08-15 19:50 ` [patch v2 5/9] btrfs: Push up clear_extent_bit " Jeff Mahoney
2011-08-15 19:50 ` [patch v2 6/9] btrfs: Push up unlock_extent " Jeff Mahoney
2011-08-15 19:50 ` Jeff Mahoney [this message]
2011-08-15 19:50 ` [patch v2 8/9] btrfs: Push up btrfs_pin_extent failures Jeff Mahoney
2011-08-15 19:50 ` [patch v2 9/9] btrfs: Push up non-looped btrfs_start_transaction failures Jeff Mahoney

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=20110815195232.912795302@suse.com \
    --to=jeffm@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.