[PATCH 1/4 RESEND] Btrfs: remove the useless assignment to *entry in function tree_insert of file extent_io.c
In tree_insert, var *entry is used in the loop only, and is useless out of the loop. Remove the useless assignment after the loop. Signed-off-by: Wang Sheng-Hui shh...@gmail.com --- fs/btrfs/extent_io.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 8d904dd..7b679e2 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -186,7 +186,6 @@ static struct rb_node *tree_insert(struct rb_root *root, u64 offset, return parent; } - entry = rb_entry(node, struct tree_entry, rb_node); rb_link_node(node, parent, p); rb_insert_color(node, root); return NULL; -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4 RESEND] Btrfs: cleanup the comment for clear_state_bit in extent_io.c
No 'delete' arg is used for clear_state_bit. Cleanup the comment. Signed-off-by: Wang Sheng-Hui shh...@gmail.com --- fs/btrfs/extent_io.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 7b679e2..5505356 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -403,8 +403,7 @@ static int split_state(struct extent_io_tree *tree, struct extent_state *orig, /* * utility function to clear some bits in an extent state struct. - * it will optionally wake up any one waiting on this state (wake == 1), or - * forcibly remove the state from the tree (delete == 1). + * it will optionally wake up any one waiting on this state (wake == 1). * * If no bits are set on the state struct after clearing things, the * struct is freed and removed from the tree -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4 RESEND] Btrfs: fix btrfs_release_extent_buffer_page with the right usage of num_extent_pages
num_extent_pages returns the number of pages in the specific range, not
the index of the last page in the eb range.
btrfs_release_extent_buffer_page is called with start_idx set 0 in current
codes, so it's not a problem yet. But the logic is indeed wrong.
Fix it here.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/extent_io.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 5505356..ddfc1d5 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3975,11 +3975,13 @@ static void btrfs_release_extent_buffer_page(struct
extent_buffer *eb,
unsigned long start_idx)
{
unsigned long index;
+ unsigned long num_pages;
struct page *page;
BUG_ON(extent_buffer_under_io(eb));
- index = num_extent_pages(eb-start, eb-len);
+ num_pages = num_extent_pages(eb-start, eb-len);
+ index = start_idx + num_pages;
if (start_idx = index)
return;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] Btrfs: fix the comment for find_first_extent_bit
The return value of find_first_extent_bit is 1 or 0, no 0. And if found something, return 0; if nothing was found, return 1. Fix the comment. Signed-off-by: Wang Sheng-Hui shh...@gmail.com --- fs/btrfs/extent_io.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index ddfc1d5..26fbe1c 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -1288,7 +1288,7 @@ out: * returned if we find something, and *start_ret and *end_ret are * set to reflect the state struct that was found. * - * If nothing was found, 1 is returned, 0 on error + * If nothing was found, 1 is returned. If found something, return 0. */ int find_first_extent_bit(struct extent_io_tree *tree, u64 start, u64 *start_ret, u64 *end_ret, int bits) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: allow mount -o remount,compress=no
On Wed, Apr 04, 2012 at 09:46:17PM +0200, Arnd Hannemann wrote:
Btrfs allows to turn on compression on a mounted and used filesystem
by issuing mount -o remount,compress=lzo.
This patch allows to turn compression off again
while the filesystem is mounted.
I agree it makes sense to allow for turning off the compression via
remount. Currently the mount flag FORCE_COMPRESS implies COMPRESS and
your code may lead to FORCE_COMPRESS without COMPRESS. To fix that
clear the force option as well.
For completeness, there should be also possibility of
-o remount,compress-force=no
doing exactly the same, just a different syntax. Proposed fix below.
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -394,15 +394,20 @@ int btrfs_parse_options(struct btrfs_root *root, char
*options)
strcmp(args[0].from, zlib) == 0) {
compress_type = zlib;
info-compress_type = BTRFS_COMPRESS_ZLIB;
+ btrfs_set_opt(info-mount_opt, COMPRESS);
} else if (strcmp(args[0].from, lzo) == 0) {
compress_type = lzo;
info-compress_type = BTRFS_COMPRESS_LZO;
+ btrfs_set_opt(info-mount_opt, COMPRESS);
+ } else if (strncmp(args[0].from, no, 2) == 0) {
+ compress_type = no;
+ info-compress_type = BTRFS_COMPRESS_NONE;
+ btrfs_clear_opt(info-mount_opt, COMPRESS);
btrfs_clear_opt(info-mount_opt,
FORCE_COMPRESS);
compress_force = false;
} else {
ret = -EINVAL;
goto out;
}
- btrfs_set_opt(info-mount_opt, COMPRESS);
if (compress_force) {
btrfs_set_opt(info-mount_opt, FORCE_COMPRESS);
pr_info(btrfs: force %s compression\n,
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[3.4-rc1] attempt to access beyond end of device and livelock
Hi Josef, Chris, When testing BTRFS with RAID 0 metadata on linux-3.4-rc1, we see discard ranges exceeding the end of the block device [1], potentially causing dataloss; when this occurs, filesystem writeback becomes catatonic due to continual resubmission. Simply mounting with discard a raid0 metadata filesystem and copying some data in [2] provokes the issue. Thanks, Daniel --- [1] attempt to access beyond end of device ram0: rw=129, want=8452072, limit=4096000 ... --- [2] modprobe brd rd_size=2048000 (or boot with ramdisk_size=2048000) mkfs.btrfs -m raid0 /dev/ram0 /dev/ram1 mount /dev/ram0 /mnt -o discard cd /mnt tar -xvzf linux.tar.gz access beyond end of device and livelock -- Daniel J Blueman -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
kernel BUG at extent-tree.c:3162 (get_restripe_target)
I'm consistently hitting the BUG_ON in the new get_restripe_target function that was added by [PATCH 4/8] Btrfs: add get_restripe_target() helper when trying to initially mount a btrfs partition. Lines fs/btrfs/extent-tree.c:3161-3162: BUG_ON(!mutex_is_locked(fs_info-volume_mutex) !spin_is_locked(fs_info-balance_lock)); The kernel is a 3.3.1 kernel merged with the for-linus branch (for the 3.4_rc kernel) of Chris Mason's git repo. If I boot with an older 3.2.10 kernel (which was merged with the 3.3_rc for-linus branch), the partition mounts without error, and btrfsck reports no errors. The partition seems to behave normally under use on the 3.2.10 kernel. This computer has gone through a few hard reboots recently. I'm not sure if the hard reboots have left some inconsistencies, but if so, they are not showing up on the 3.2.10 kernel. [ 66.233463] device fsid 43129e18-c745-476c-ba48-c6bea0d71e56 devid 1 transid 151 /dev/sdc1 [ 66.235090] btrfs: force lzo compression [ 66.235097] btrfs: enabling auto defrag [ 66.235099] btrfs: disk space caching is enabled [ 66.310693] [ cut here ] [ 66.310802] kernel BUG at fs/btrfs/extent-tree.c:3162! [ 66.310905] invalid opcode: [#1] [ 66.311042] Modules linked in: [ 66.311178] [ 66.311274] Pid: 2993, comm: mount Not tainted 3.3.1-git-local+ #1 /MS-6570 [ 66.311549] EIP: 0060:[c12db3f6] EFLAGS: 00010246 CPU: 0 [ 66.311573] EIP is at get_restripe_target+0x86/0x90 [ 66.311573] EAX: 0001 EBX: 0001 ECX: EDX: 0001 [ 66.311573] ESI: 0001 EDI: f6227780 EBP: f4d9dc80 ESP: f4d9dc7c [ 66.311573] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 66.311573] Process mount (pid: 2993, ti=f4d9c000 task=f5f5e180 task.ti=f4d9c000) [ 66.311573] Stack: [ 66.311573] 0001 f4d9dca4 c12e1693 0001 f6379000 [ 66.311573] f31d f61b5400 f4d9dcb0 c12e1797 0001 f4d9dd38 c12e8a3a f31d [ 66.311573] f4d9dd28 f31d f61b5400 0033 f61b5510 [ 66.311573] Call Trace: [ 66.311573] [c12e1693] btrfs_reduce_alloc_profile+0x43/0xe0 [ 66.311573] [c12e1797] get_alloc_profile+0x67/0x70 [ 66.311573] [c12e8a3a] btrfs_read_block_groups+0x4fa/0x650 [ 66.311573] [c12f40d0] open_ctree+0x10e0/0x18b0 [ 66.311573] [c12d2271] btrfs_mount+0x501/0x8e0 [ 66.311573] [c10a5055] ? free_pages_prepare+0xc5/0x120 [ 66.311573] [c10a6815] ? __free_pages+0x25/0x30 [ 66.311573] [c10a684f] ? free_pages+0x2f/0x40 [ 66.311573] [c10d67d5] mount_fs+0x35/0x180 [ 66.311573] [c10b540e] ? kstrdup+0x3e/0x50 [ 66.311573] [c10eab4b] vfs_kern_mount+0x4b/0xb0 [ 66.311573] [c10ead09] do_kern_mount+0x39/0xd0 [ 66.311573] [c10ec48a] do_mount+0x58a/0x670 [ 66.311573] [c10a6066] ? __get_free_pages+0x26/0x30 [ 66.311573] [c10ebde9] ? copy_mount_options+0x39/0x110 [ 66.311573] [c10ec5f6] sys_mount+0x66/0xa0 [ 66.311573] [c1789293] sysenter_do_call+0x12/0x22 [ 66.311573] Code: b6 00 00 00 00 31 c0 31 d2 83 e3 04 74 cc f6 81 cd 00 00 00 01 74 c3 8b 99 c4 00 00 00 8b 91 c8 00 00 00 89 d8 83 c8 04 5b 5d c3 0f 0b 90 8d b4 26 00 00 00 00 55 8d 88 f0 fe ff ff 89 e5 53 8b [ 66.311573] EIP: [c12db3f6] get_restripe_target+0x86/0x90 SS:ESP 0068:f4d9dc7c [ 66.318545] ---[ end trace 0c923804dee2b085 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at extent-tree.c:3162 (get_restripe_target)
On Fri, Apr 06, 2012 at 10:33:04AM -0500, Mitch Harder wrote: I'm consistently hitting the BUG_ON in the new get_restripe_target function that was added by [PATCH 4/8] Btrfs: add get_restripe_target() helper when trying to initially mount a btrfs partition. Lines fs/btrfs/extent-tree.c:3161-3162: BUG_ON(!mutex_is_locked(fs_info-volume_mutex) !spin_is_locked(fs_info-balance_lock)); Is it a single CPU machine? See http://www.spinics.net/lists/linux-btrfs/msg15884.html david -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at extent-tree.c:3162 (get_restripe_target)
On Fri, Apr 6, 2012 at 10:43 AM, David Sterba d...@jikos.cz wrote: On Fri, Apr 06, 2012 at 10:33:04AM -0500, Mitch Harder wrote: I'm consistently hitting the BUG_ON in the new get_restripe_target function that was added by [PATCH 4/8] Btrfs: add get_restripe_target() helper when trying to initially mount a btrfs partition. Lines fs/btrfs/extent-tree.c:3161-3162: BUG_ON(!mutex_is_locked(fs_info-volume_mutex) !spin_is_locked(fs_info-balance_lock)); Is it a single CPU machine? See http://www.spinics.net/lists/linux-btrfs/msg15884.html Thanks! Yes, this is a single CPU machine. I'll test the solution from that thread. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at extent-tree.c:3162 (get_restripe_target)
On Fri, Apr 06, 2012 at 10:52:13AM -0500, Mitch Harder wrote: On Fri, Apr 6, 2012 at 10:43 AM, David Sterba d...@jikos.cz wrote: On Fri, Apr 06, 2012 at 10:33:04AM -0500, Mitch Harder wrote: I'm consistently hitting the BUG_ON in the new get_restripe_target function that was added by [PATCH 4/8] Btrfs: add get_restripe_target() helper when trying to initially mount a btrfs partition. Lines fs/btrfs/extent-tree.c:3161-3162: BUG_ON(!mutex_is_locked(fs_info-volume_mutex) !spin_is_locked(fs_info-balance_lock)); Is it a single CPU machine? See http://www.spinics.net/lists/linux-btrfs/msg15884.html Thanks! Yes, this is a single CPU machine. I'll test the solution from that thread. Sorry about that. I'm going to hold off a bit to see if there will be any objections to v2 from that thread, but we will definitely do something about this by rc3 or rc4 at worst. Thanks, Ilya -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs, lockdep: get_restripe_target: use lockdep in BUG_ON
On Thu, Apr 5, 2012 at 11:51 AM, Ilya Dryomov idryo...@gmail.com wrote: On Thu, Apr 05, 2012 at 12:23:01PM -0400, Bobby Powers wrote: On Wed, Apr 4, 2012 at 10:04 PM, Bobby Powers bobbypow...@gmail.com wrote: spin_is_locked always returns 0 on non-SMP systems, which causes btrfs to fail the mount. There is documentation pending as to why checking I guess I should be explicit in stating that this is a regression, so this patch or something else that addresses it should be pulled into 3.4. Yes, this is a regression and spin_is_locked() definitely has to go. I don't have a strong opinion on this assert, if there are objections to v2 I'm OK with ripping that BUG_ON entirely and replacing it with a comment (this function and its callers are WIP). I'm still hitting this BUG_ON after applying this patch on my single CPU AthlonXP x86 system. I'm running a 3.3.1 kernel merged with the for-linus branch, and had this patch applied. I am currently testing with the BUG_ON commented out. The btrfs partitions mount without error, and I haven't encountered any immediate issues. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs, lockdep: get_restripe_target: use lockdep in BUG_ON
On Wed, Apr 04, 2012 at 10:04:12PM -0400, Bobby Powers wrote:
spin_is_locked always returns 0 on non-SMP systems, which causes btrfs
to fail the mount. There is documentation pending as to why checking
for spin_is_locked is a bad idea:
https://lkml.org/lkml/2012/3/27/413
The suggested lockdep_assert_held() is not appropriate in this case,
as what get_restripe_target() is checking for is that either
volume_mutex is held or balance_lock is held. Luckily
lockdep_assert_held() is a simple macro:
WARN_ON(debug_locks !lockdep_is_held(l))
We can mimic the structure in get_restripe_target(), but we need to
make sure lockdep_is_held() is defined for the !LOCKDEP case.
CC: Ilya Dryomov idryo...@gmail.com
CC: Chris Mason chris.ma...@oracle.com
CC: Andi Kleen a...@linux.intel.com
CC: Jeff Mahoney je...@suse.de
CC: Ingo Molnar mi...@redhat.com
CC: linux-ker...@vger.kernel.org
Signed-off-by: Bobby Powers bobbypow...@gmail.com
---
fs/btrfs/extent-tree.c |5 +++--
include/linux/lockdep.h |1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index a844204..4d13eb1 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -24,6 +24,7 @@
#include linux/kthread.h
#include linux/slab.h
#include linux/ratelimit.h
+#include linux/lockdep.h
#include compat.h
#include hash.h
#include ctree.h
@@ -3158,8 +3159,8 @@ static u64 get_restripe_target(struct btrfs_fs_info
*fs_info, u64 flags)
struct btrfs_balance_control *bctl = fs_info-balance_ctl;
u64 target = 0;
- BUG_ON(!mutex_is_locked(fs_info-volume_mutex)
-!spin_is_locked(fs_info-balance_lock));
+ BUG_ON(debug_locks !lockdep_is_held(fs_info-volume_mutex)
+!lockdep_is_held(fs_info-balance_lock));
if (!bctl)
return 0;
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index d36619e..94c0edb 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -392,6 +392,7 @@ struct lock_class_key { };
#define lockdep_depth(tsk) (0)
+#define lockdep_is_held(l) (0)
#define lockdep_assert_held(l) do { } while (0)
#define lockdep_recursing(tsk) (0)
--
1.7.10.rc3.3.g19a6c
OK, Mitch's report prompted me to actually take a look. This patch is
wrong: by defining lockdep_is_held(l) to 0 in !LOCKDEP case you
effectively mimic the behaviour of spin_is_locked() which is what
getting us in the first place.
get_restripe_target() interface is WIP so I will replace BUG_ON with a
comment and send a patch through btrfs tree.
Thanks,
Ilya
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
HONG LEONG BANK (Malaysia)
Hello, I contacted you to assist in distributing the money left behind by my late client, Edward Cheah, Tele:+60146308549 Fax:+60(0)321784290 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs, lockdep: get_restripe_target: use lockdep in BUG_ON
On Fri, Apr 6, 2012 at 4:05 PM, Ilya Dryomov idryo...@gmail.com wrote:
On Wed, Apr 04, 2012 at 10:04:12PM -0400, Bobby Powers wrote:
spin_is_locked always returns 0 on non-SMP systems, which causes btrfs
to fail the mount. There is documentation pending as to why checking
for spin_is_locked is a bad idea:
https://lkml.org/lkml/2012/3/27/413
The suggested lockdep_assert_held() is not appropriate in this case,
as what get_restripe_target() is checking for is that either
volume_mutex is held or balance_lock is held. Luckily
lockdep_assert_held() is a simple macro:
WARN_ON(debug_locks !lockdep_is_held(l))
We can mimic the structure in get_restripe_target(), but we need to
make sure lockdep_is_held() is defined for the !LOCKDEP case.
CC: Ilya Dryomov idryo...@gmail.com
CC: Chris Mason chris.ma...@oracle.com
CC: Andi Kleen a...@linux.intel.com
CC: Jeff Mahoney je...@suse.de
CC: Ingo Molnar mi...@redhat.com
CC: linux-ker...@vger.kernel.org
Signed-off-by: Bobby Powers bobbypow...@gmail.com
---
fs/btrfs/extent-tree.c | 5 +++--
include/linux/lockdep.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index a844204..4d13eb1 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -24,6 +24,7 @@
#include linux/kthread.h
#include linux/slab.h
#include linux/ratelimit.h
+#include linux/lockdep.h
#include compat.h
#include hash.h
#include ctree.h
@@ -3158,8 +3159,8 @@ static u64 get_restripe_target(struct btrfs_fs_info
*fs_info, u64 flags)
struct btrfs_balance_control *bctl = fs_info-balance_ctl;
u64 target = 0;
- BUG_ON(!mutex_is_locked(fs_info-volume_mutex)
- !spin_is_locked(fs_info-balance_lock));
+ BUG_ON(debug_locks !lockdep_is_held(fs_info-volume_mutex)
+ !lockdep_is_held(fs_info-balance_lock));
if (!bctl)
return 0;
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index d36619e..94c0edb 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -392,6 +392,7 @@ struct lock_class_key { };
#define lockdep_depth(tsk) (0)
+#define lockdep_is_held(l) (0)
#define lockdep_assert_held(l) do { } while (0)
#define lockdep_recursing(tsk) (0)
--
1.7.10.rc3.3.g19a6c
OK, Mitch's report prompted me to actually take a look. This patch is
wrong: by defining lockdep_is_held(l) to 0 in !LOCKDEP case you
effectively mimic the behaviour of spin_is_locked() which is what
getting us in the first place.
get_restripe_target() interface is WIP so I will replace BUG_ON with a
comment and send a patch through btrfs tree.
Hah, good point...
Thanks,
Ilya
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
