linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fusionio.com>
To: David Sterba <dave@jikos.cz>
Cc: Tsutomu Itoh <t-itoh@jp.fujitsu.com>,
	"Chris L. Mason" <clmason@fusionio.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Josef Bacik <JBacik@fusionio.com>
Subject: Re: [PATCH] Btrfs: check return value of btrfs_set_extent_delalloc()
Date: Tue, 26 Jun 2012 09:42:12 -0400	[thread overview]
Message-ID: <20120626134211.GC2046@localhost.localdomain> (raw)
In-Reply-To: <20120626132653.GS28144@twin.jikos.cz>

On Tue, Jun 26, 2012 at 07:26:53AM -0600, David Sterba wrote:
> On Tue, Jun 26, 2012 at 12:22:10PM +0900, Tsutomu Itoh wrote:
> > btrfs_set_extent_delalloc() has the possibility of returning the error.
> > So I add the code in which the return value of btrfs_set_extent_delalloc()
> > is checked.
> 
> The caller is cluster_pages_for_defrag, the only error I see returned
> via __set_extent_bit is -EEXIST, other errors BUG directly or via
> extent_io_tree_panic() .
> 
> If the error happens, then the [page_start,page_end-1] is already set
> for delalloc, that's probably a bug and should be caught.
> 
> There are two more unchecked calls to btrfs_set_extent_delalloc:
> 
> inode.c:btrfs_writepage_fixup_worker
> 
> 1729         btrfs_set_extent_delalloc(inode, page_start, page_end, &cached_state);
> 1730         ClearPageChecked(page);
> 1731         set_page_dirty(page);
> 
> IIRC from the days full of fixup worker fun, the reason why this is safe
> to ignore is because the call chain leading here is exactly due to missing
> delalloc bits on the page.
> 
> relocation.c:relocate_file_extent_cluster
> 
> 3034                 btrfs_set_extent_delalloc(inode, page_start, page_end, NULL);
> 3035                 set_page_dirty(page);
> 
> hmm relocation ... :)
> 
> 
> Anyway, I'd like to let Josef take another look at your patch.
>

Even better, we clear delalloc right before doing the set and we have the pages
locked, so theres no way we can get EEXIST here, so I'll just drop this patch.
Thanks Dave,

Josef 

      reply	other threads:[~2012-06-26 13:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-26  3:22 [PATCH] Btrfs: check return value of btrfs_set_extent_delalloc() Tsutomu Itoh
2012-06-26 13:26 ` David Sterba
2012-06-26 13:42   ` Josef Bacik [this message]

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=20120626134211.GC2046@localhost.localdomain \
    --to=jbacik@fusionio.com \
    --cc=clmason@fusionio.com \
    --cc=dave@jikos.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=t-itoh@jp.fujitsu.com \
    /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;
as well as URLs for NNTP newsgroup(s).