[PATCH]Fix buffer get/release issue in create_snapshot

Hello,

'__btrfs_cow_block' expects the caller holds a reference to the buffer
and it drops caller's reference.  If the caller doesn't hold a
reference, root->commit_root's reference may lose.

Regards
YZ
diff -r 66ea50b1a761 inode.c
--- a/inode.c	Tue Nov 20 13:44:45 2007 -0500
+++ b/inode.c	Tue Dec 04 18:32:38 2007 +0800
 <at>  <at>  -2035,7 +2035,9  <at>  <at>  static int create_snapshot(struct btrfs_
 	key.offset = 1;
 	btrfs_set_key_type(&key, BTRFS_ROOT_ITEM_KEY);

+	extent_buffer_get(root->node);
 	btrfs_cow_block(trans, root, root->node, NULL, 0, &tmp);
+	free_extent_buffer(&tmp);
 	btrfs_set_root_bytenr(&new_root_item, root->node->start);
 	btrfs_set_root_level(&new_root_item, btrfs_header_level(root->node));

Re: [PATCH]Fix buffer get/release issue in create_snapshot

Sorry, there is a typo in previous patch.

---
diff -r 66ea50b1a761 inode.c
--- a/inode.c	Tue Nov 20 13:44:45 2007 -0500
+++ b/inode.c	Tue Dec 04 21:38:06 2007 +0800
 <at>  <at>  -2035,7 +2035,9  <at>  <at>  static int create_snapshot(struct btrfs_
 	key.offset = 1;
 	btrfs_set_key_type(&key, BTRFS_ROOT_ITEM_KEY);

+	extent_buffer_get(root->node);
 	btrfs_cow_block(trans, root, root->node, NULL, 0, &tmp);
+	free_extent_buffer(tmp);
 	btrfs_set_root_bytenr(&new_root_item, root->node->start);
 	btrfs_set_root_level(&new_root_item, btrfs_header_level(root->node));

Re: [PATCH]Fix buffer get/release issue in create_snapshot

On Tue, 4 Dec 2007 21:22:44 +0800
"Yan Zheng" <yanzheng <at> 21cn.com> wrote:

> Hello,
> 
> '__btrfs_cow_block' expects the caller holds a reference to the buffer
> and it drops caller's reference.  If the caller doesn't hold a
> reference, root->commit_root's reference may lose.

Thanks, I've got the updated patch.

-chris

[ANNOUNCE] Btrfs v0.9

Hello everyone,

I've just tagged and released Btrfs v0.9.  Special thanks to Yan Zheng
and Josef Bacik for their work.

This release includes a number of disk format changes from v0.8 and
also a small change from recent btrfs-unstable HG trees.  So, if you
have existing Btrfs filesystems, you will need to backup, reformat and
restore to try out v0.9.

You can find download links and other details here:

http://oss.oracle.com/projects/btrfs/

Since v0.8:

* Support for btree blocks larger than the page size.  mkfs.btrfs
defaults to 8k blocks, but -l and -n can be used to set the block size
for leaves and nodes.  Powers of 2 are required, example:

mkfs.btrfs -l 32768 -n 32768 /dev/xxxx

* Support for inline (packed into the btree) file data larger than the
page size.  Any file smaller than a btree block will probably be backed
into the btree.

* Xattr support (no ACLs yet) from Josef Bacik.  This works for generic
user xattrs and was tested with beagle among other things.

* Stripe size parameter to mkfs.btrfs (-s size_in_bytes).  Extents will

[PATCH]Updates for btrfs-progs

Hello,

This patch updates some files in btrfs-progs according to kernel
module's codes.

Regards
YZ
---
diff -r 65f1b7acb8ba ctree.c
--- a/ctree.c	Tue Dec 04 15:11:12 2007 -0500
+++ b/ctree.c	Wed Dec 05 21:02:17 2007 +0800
 <at>  <at>  -19,15 +19,16  <at>  <at> 
 #include <stdio.h>
 #include <stdlib.h>
 #include "kerncompat.h"
-#include "radix-tree.h"
 #include "ctree.h"
 #include "disk-io.h"
+#include "transaction.h"
 #include "print-tree.h"

 static int split_node(struct btrfs_trans_handle *trans, struct btrfs_root
 		      *root, struct btrfs_path *path, int level);
 static int split_leaf(struct btrfs_trans_handle *trans, struct btrfs_root
-		      *root, struct btrfs_path *path, int data_size);
+		      *root, struct btrfs_key *ins_key,
+		      struct btrfs_path *path, int data_size, int extend);
 static int push_node_left(struct btrfs_trans_handle *trans, struct btrfs_root
 			  *root, struct btrfs_buffer *dst, struct btrfs_buffer
 			  *src);

[PATCH] Makefile: CFLAGS, LDFLAGS

Split CFLAGS into CFLAGS (user part) and AM_CFLAGS (not-so-user part;
variable name taken from automake, but otherwise no relation).
Also add LDFLAGS.
This allows me to use `make CFLAGS="-O2 -fPIE" LDFLAGS="-pie"` without
dropping the other important (AM_CFLAGS) flags.

Signed-off-by: Jan Engelhardt <jengelh <at> computergmbh.de>

---
 btrfs-progs/Makefile |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

Index: btrfs-0.9/btrfs-progs/Makefile
===================================================================
--- btrfs-0.9.orig/btrfs-progs/Makefile
+++ btrfs-0.9/btrfs-progs/Makefile
 <at>  <at>  -1,5 +1,6  <at>  <at> 
 CC=gcc
-CFLAGS = -g -Wall -fno-strict-aliasing -Werror -D_FILE_OFFSET_BITS=64
+AM_CFLAGS = -Wall -fno-strict-aliasing -D_FILE_OFFSET_BITS=64
+CFLAGS = -g -Werror
 objects = ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o \
 	  root-tree.o dir-item.o hash.o file-item.o inode-item.o \
 	  inode-map.o crc32c.o rbtree.o extent-cache.o \
 <at>  <at>  -23,28 +24,28  <at>  <at>  endif

 .c.o:
 	$(check) $<
-	$(CC) $(DEPFLAGS) $(CFLAGS) -c $<
+	$(CC) $(DEPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c $<

section mismatch warnings

Hello everybody,

compiling btrfs into the kernel results in section mismatch warnings. __exit 
functions are called where they are not allowed to. The attached patch fixes 
this for me. Not sure if it is correct though.

Signed-off-by: Christian Hesse <mail <at> earthworm.de>
--

-- 
Regards,
Chris

_______________________________________________
Btrfs-devel mailing list
Btrfs-devel <at> oss.oracle.com
http://oss.oracle.com/mailman/listinfo/btrfs-devel

Oops

Hello everybody,

I've my Gentoo's /usr/portage on a loopback btrfs. Just wanted to sync and got 
an oops. I've a rsync and a ls process in status D now. The system has been 
in suspend (tuxonice 3.0-rc3) with mounted btrfs, perhaps that is related?

Dec  7 19:18:38 revo BUG: unable to handle kernel NULL pointer dereference at 
virtual address 0000000c
Dec  7 19:18:38 revo printing eip: b01dcd24 *pde = 00000000
Dec  7 19:18:38 revo Oops: 0000 [#1] SMP
Dec  7 19:18:38 revo Modules linked in: iwl3945 vboxdrv
Dec  7 19:18:38 revo
Dec  7 19:18:38 revo Pid: 9464, comm: rsync Not tainted (2.6.24-rc4 #1)
Dec  7 19:18:38 revo EIP: 0060:[<b01dcd24>] EFLAGS: 00210282 CPU: 0
Dec  7 19:18:38 revo EIP is at btrfs_set_key_blockptr+0x14/0x100
Dec  7 19:18:38 revo EAX: 00000000 EBX: 00000060 ECX: 10006000 EDX: 0000004f
Dec  7 19:18:38 revo ESI: 00000000 EDI: eb1293e4 EBP: eec7cbd4 ESP: c4d99c34
Dec  7 19:18:38 revo dhcpcd[8448]: wlan0: renewing lease of 192.168.182.74
Dec  7 19:18:38 revo DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Dec  7 19:18:38 revo Process rsync (pid: 9464, ti=c4d98000 task=e0544ab0 
task.ti=c4d98000)
Dec  7 19:18:38 revo Stack: 00000000 eb1293e4 eec7c6f4 06040048 00000000 
20000000 000000dd 00000000
Dec  7 19:18:38 revo 00000000 00000000 00000000 eb1293e4 b01bf3e7 10006000 
00000000 00000000
Dec  7 19:18:38 revo 00000000 da25be70 ee8e1400 eec7c6f4 00000000 000001df 
00000000 eb1293e4
Dec  7 19:18:38 revo Call Trace:
Dec  7 19:18:38 revo [<b01bf3e7>] __btrfs_cow_block+0x1c7/0x390
Dec  7 19:18:38 revo [<b01bf726>] btrfs_cow_block+0x176/0x1a0

Re: Oops

On Fri, 7 Dec 2007 19:27:43 +0100
Christian Hesse <list <at> eworm.de> wrote:

> Hello everybody,
> 
> I've my Gentoo's /usr/portage on a loopback btrfs. Just wanted to
> sync and got an oops. I've a rsync and a ls process in status D now.
> The system has been in suspend (tuxonice 3.0-rc3) with mounted btrfs,
> perhaps that is related?

Could be, but only if other filesystems get problems during suspend as
well.

Which version of btrfs was used to format this disk, and which one was
in use when you got the oops?

You're oopsing because the parent pointer for btrfs_cow_block was null,
but the buffer you were trying to cow wasn't the root.  That's not
supposed to happen ;)

-chris

> 
> Dec  7 19:18:38 revo BUG: unable to handle kernel NULL pointer
> dereference at virtual address 0000000c
> Dec  7 19:18:38 revo printing eip: b01dcd24 *pde = 00000000
> Dec  7 19:18:38 revo Oops: 0000 [#1] SMP
> Dec  7 19:18:38 revo Modules linked in: iwl3945 vboxdrv
> Dec  7 19:18:38 revo
> Dec  7 19:18:38 revo Pid: 9464, comm: rsync Not tainted (2.6.24-rc4

Re: Oops

On Friday 07 December 2007, Chris Mason wrote:
> On Fri, 7 Dec 2007 19:27:43 +0100
> Christian Hesse <list <at> eworm.de> wrote:
> > Hello everybody,
> >
> > I've my Gentoo's /usr/portage on a loopback btrfs. Just wanted to
> > sync and got an oops. I've a rsync and a ls process in status D now.
> > The system has been in suspend (tuxonice 3.0-rc3) with mounted btrfs,
> > perhaps that is related?
>
> Could be, but only if other filesystems get problems during suspend as
> well.

No, other filesystems are fine.

> Which version of btrfs was used to format this disk, and which one was
> in use when you got the oops?

Both 0.9, kernel and userspace.

> You're oopsing because the parent pointer for btrfs_cow_block was null,
> but the buffer you were trying to cow wasn't the root.  That's not
> supposed to happen ;)

I think so. ;) Let me know if I can help to debug that.

> > Dec  7 19:18:38 revo BUG: unable to handle kernel NULL pointer
> > dereference at virtual address 0000000c
> > Dec  7 19:18:38 revo printing eip: b01dcd24 *pde = 00000000
> > Dec  7 19:18:38 revo Oops: 0000 [#1] SMP