This is a note to let you know that I've just added the patch titled
btrfs: fix use of uninit "ret" in end_extent_writepage()
to the 3.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
btrfs-fix-use-of-uninit-ret-in-end_extent_writepage.patch
and it can be found in the queue-3.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From 3e2426bd0eb980648449e7a2f5a23e3cd3c7725c Mon Sep 17 00:00:00 2001
From: Eric Sandeen <[email protected]>
Date: Thu, 12 Jun 2014 00:39:58 -0500
Subject: btrfs: fix use of uninit "ret" in end_extent_writepage()
From: Eric Sandeen <[email protected]>
commit 3e2426bd0eb980648449e7a2f5a23e3cd3c7725c upstream.
If this condition in end_extent_writepage() is false:
if (tree->ops && tree->ops->writepage_end_io_hook)
we will then test an uninitialized "ret" at:
ret = ret < 0 ? ret : -EIO;
The test for ret is for the case where ->writepage_end_io_hook
failed, and we'd choose that ret as the error; but if
there is no ->writepage_end_io_hook, nothing sets ret.
Initializing ret to 0 should be sufficient; if
writepage_end_io_hook wasn't set, (!uptodate) means
non-zero err was passed in, so we choose -EIO in that case.
Signed-of-by: Eric Sandeen <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/extent_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2354,7 +2354,7 @@ int end_extent_writepage(struct page *pa
{
int uptodate = (err == 0);
struct extent_io_tree *tree;
- int ret;
+ int ret = 0;
tree = &BTRFS_I(page->mapping->host)->io_tree;
Patches currently in stable-queue which might be from [email protected] are
queue-3.15/btrfs-fix-use-of-uninit-ret-in-end_extent_writepage.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
