All of lore.kernel.org
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: bo.li.liu@oracle.com, dsterba@suse.com,
	gregkh@linuxfoundation.org, vegard.nossum@oracle.com
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "Btrfs: bail out if block group has different mixed flag" has been added to the 4.8-stable tree
Date: Wed, 04 Jan 2017 10:40:52 +0100	[thread overview]
Message-ID: <148352285217821@kroah.com> (raw)


This is a note to let you know that I've just added the patch titled

    Btrfs: bail out if block group has different mixed flag

to the 4.8-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-bail-out-if-block-group-has-different-mixed-flag.patch
and it can be found in the queue-4.8 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From 49303381f19ab16a371a061b67e783d3f570d56e Mon Sep 17 00:00:00 2001
From: Liu Bo <bo.li.liu@oracle.com>
Date: Thu, 25 Aug 2016 18:08:27 -0700
Subject: Btrfs: bail out if block group has different mixed flag

From: Liu Bo <bo.li.liu@oracle.com>

commit 49303381f19ab16a371a061b67e783d3f570d56e upstream.

Currently we allow inconsistence about mixed flag
 (BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_DATA).

We'd get ENOSPC if block group has mixed flag and btrfs doesn't.
If that happens, we have one space_info with mixed flag and another
space_info only with BTRFS_BLOCK_GROUP_METADATA, and
global_block_rsv.space_info points to the latter one, but all bytes
from block_group contributes to the mixed space_info, thus all the
allocation will fail with ENOSPC.

This adds a check for the above case.

Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
[ updated message ]
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/btrfs/extent-tree.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -10127,6 +10127,11 @@ int btrfs_read_block_groups(struct btrfs
 	struct extent_buffer *leaf;
 	int need_clear = 0;
 	u64 cache_gen;
+	u64 feature;
+	int mixed;
+
+	feature = btrfs_super_incompat_flags(info->super_copy);
+	mixed = !!(feature & BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS);
 
 	root = info->extent_root;
 	key.objectid = 0;
@@ -10180,6 +10185,15 @@ int btrfs_read_block_groups(struct btrfs
 				   btrfs_item_ptr_offset(leaf, path->slots[0]),
 				   sizeof(cache->item));
 		cache->flags = btrfs_block_group_flags(&cache->item);
+		if (!mixed &&
+		    ((cache->flags & BTRFS_BLOCK_GROUP_METADATA) &&
+		    (cache->flags & BTRFS_BLOCK_GROUP_DATA))) {
+			btrfs_err(info,
+"bg %llu is a mixed block group but filesystem hasn't enabled mixed block groups",
+				  cache->key.objectid);
+			ret = -EINVAL;
+			goto error;
+		}
 
 		key.objectid = found_key.objectid + found_key.offset;
 		btrfs_release_path(path);


Patches currently in stable-queue which might be from bo.li.liu@oracle.com are

queue-4.8/btrfs-fix-memory-leak-in-reading-btree-blocks.patch
queue-4.8/btrfs-fix-emptiness-check-for-dirtied-extent-buffers-at-check_leaf.patch
queue-4.8/btrfs-bail-out-if-block-group-has-different-mixed-flag.patch
queue-4.8/btrfs-return-gracefully-from-balance-if-fs-tree-is-corrupted.patch
queue-4.8/btrfs-don-t-bug-during-drop-snapshot.patch
queue-4.8/btrfs-fix-bug_on-in-btrfs_mark_buffer_dirty.patch
queue-4.8/btrfs-fix-memory-leak-in-do_walk_down.patch

                 reply	other threads:[~2017-01-04  9:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=148352285217821@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=bo.li.liu@oracle.com \
    --cc=dsterba@suse.com \
    --cc=stable-commits@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=vegard.nossum@oracle.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 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.