From: Omar Sandoval <osandov@osandov.com>
To: Chris Mason <clm@fb.com>, Josef Bacik <jbacik@fb.com>,
David Sterba <dsterba@suse.cz>
Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] btrfs: handle race on ENOMEM in alloc_extent_buffer
Date: Tue, 17 Feb 2015 10:44:15 -0800 [thread overview]
Message-ID: <20150217184415.GA3297@mew> (raw)
In-Reply-To: <4fcdbbd7d6dc95598323b46dcf5db4356cb7dee8.1424168589.git.osandov@osandov.com>
On Tue, Feb 17, 2015 at 02:51:08AM -0800, Omar Sandoval wrote:
> Consider the following interleaving of overlapping calls to
> alloc_extent_buffer:
>
> Call 1:
>
> - Successfully allocates a few pages with find_or_create_page
> - find_or_create_page fails, goto free_eb
> - Unlocks the allocated pages
>
> Call 2:
> - Calls find_or_create_page and gets a page in call 1's extent_buffer
> - Finds that the page is already associated with an extent_buffer
> - Grabs a reference to the half-written extent_buffer and calls
> mark_extent_buffer_accessed on it
>
> mark_extent_buffer_accessed will then try to call mark_page_accessed on
> a null page and panic.
>
> The fix is to clear page->private of the half-written extent_buffer's
> pages all at once while holding mapping->private_lock.
>
> Signed-off-by: Omar Sandoval <osandov@osandov.com>
> ---
> fs/btrfs/extent_io.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
[snip]
Actually, I just realized that there's a simpler fix. I can resend the
whole series for easier merging once I get some review, but for now,
here's what I'm talking about:
btrfs: handle race on ENOMEM in alloc_extent_buffer
Consider the following interleaving of overlapping calls to
alloc_extent_buffer:
Call 1:
- Successfully allocates a few pages with find_or_create_page
- find_or_create_page fails, goto free_eb
- Unlocks the allocated pages
Call 2:
- Calls find_or_create_page and gets a page in call 1's extent_buffer
- Finds that the page is already associated with an extent_buffer
- Grabs a reference to the half-written extent_buffer and calls
mark_extent_buffer_accessed on it
mark_extent_buffer_accessed will then try to call mark_page_accessed on
a null page and panic.
The fix is to decrement the reference count on the half-written
extent_buffer before unlocking the pages so call 2 won't use it. We also
set exists = NULL in the case that we don't use exists to avoid
accidentally returning a freed extent_buffer in an error case.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
---
fs/btrfs/extent_io.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 790dbae..6b3cd72 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -4850,6 +4850,7 @@ struct extent_buffer *alloc_extent_buffer(struct btrfs_fs_info *fs_info,
mark_extent_buffer_accessed(exists, p);
goto free_eb;
}
+ exists = NULL;
/*
* Do this so attach doesn't complain and we need to
@@ -4913,12 +4914,12 @@ again:
return eb;
free_eb:
+ WARN_ON(!atomic_dec_and_test(&eb->refs));
for (i = 0; i < num_pages; i++) {
if (eb->pages[i])
unlock_page(eb->pages[i]);
}
- WARN_ON(!atomic_dec_and_test(&eb->refs));
btrfs_release_extent_buffer(eb);
return exists;
}
--
Omar
next prev parent reply other threads:[~2015-02-17 18:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-17 10:51 [PATCH 0/3] btrfs: ENOMEM bugfixes Omar Sandoval
2015-02-17 10:51 ` [PATCH 1/3] btrfs: handle ENOMEM in btrfs_alloc_tree_block Omar Sandoval
2015-02-17 10:51 ` [PATCH 2/3] btrfs: handle race on ENOMEM in alloc_extent_buffer Omar Sandoval
2015-02-17 18:44 ` Omar Sandoval [this message]
2015-02-17 10:51 ` [PATCH 3/3] btrfs: check io_ctl_prepare_pages return in __btrfs_write_out_cache Omar Sandoval
2015-02-22 14:58 ` Liu Bo
2015-02-20 21:20 ` [PATCH 0/3] btrfs: ENOMEM bugfixes Omar Sandoval
2015-02-20 21:22 ` Josef Bacik
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=20150217184415.GA3297@mew \
--to=osandov@osandov.com \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--cc=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@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.