[Patch] btrfs-image.c: fix return values
- Exit with non-zero when fail;
- Don't exit in non-main functions, return.
Signed-off-by: WANG Cong wangc...@zeuux.org
---
diff --git a/btrfs-image.c b/btrfs-image.c
index 9925bdb..62b3dd8 100644
--- a/btrfs-image.c
+++ b/btrfs-image.c
@@ -741,7 +741,7 @@ static int restore_metadump(const char *input, FILE *out,
int num_threads)
in = fopen(input, r);
if (!in) {
perror(unable to open metadump image);
- exit(1);
+ return 1;
}
}
@@ -760,7 +760,7 @@ static int restore_metadump(const char *input, FILE *out,
int num_threads)
if (le64_to_cpu(header-magic) != HEADER_MAGIC ||
le64_to_cpu(header-bytenr) != bytenr) {
fprintf(stderr, bad header in metadump image\n);
- exit(1);
+ return 1;
}
ret = add_cluster(cluster, mdrestore, bytenr);
BUG_ON(ret);
@@ -850,5 +850,5 @@ int main(int argc, char *argv[])
else
fclose(out);
- exit(0);
+ exit(ret);
}
--
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] Btrfs: use BTRFS_VOL_NAME_MAX for struct btrfs_ioctl_vol_args
I found userspace tool, btrfsctl, uses BTRFS_VOL_NAME_MAX, and
it also looks that this one is more proper.
Kill BTRFS_PATH_NAME_MAX since no one will use it.
Signed-off-by: WANG Cong wangc...@zeuux.org
Cc: Chris Mason chris.ma...@oracle.com
---
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index c2aa33e..f229950 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -472,7 +472,7 @@ static int btrfs_ioctl_resize(struct btrfs_root *root, void
__user *arg)
goto out;
}
- vol_args-name[BTRFS_PATH_NAME_MAX] = '\0';
+ vol_args-name[BTRFS_VOL_NAME_MAX] = '\0';
namelen = strlen(vol_args-name);
mutex_lock(root-fs_info-volume_mutex);
@@ -576,7 +576,7 @@ static noinline int btrfs_ioctl_snap_create(struct file
*file,
goto out;
}
- vol_args-name[BTRFS_PATH_NAME_MAX] = '\0';
+ vol_args-name[BTRFS_VOL_NAME_MAX] = '\0';
namelen = strlen(vol_args-name);
if (strchr(vol_args-name, '/')) {
ret = -EINVAL;
@@ -685,7 +685,7 @@ static long btrfs_ioctl_add_dev(struct btrfs_root *root,
void __user *arg)
ret = -EFAULT;
goto out;
}
- vol_args-name[BTRFS_PATH_NAME_MAX] = '\0';
+ vol_args-name[BTRFS_VOL_NAME_MAX] = '\0';
ret = btrfs_init_new_device(root, vol_args-name);
out:
@@ -713,7 +713,7 @@ static long btrfs_ioctl_rm_dev(struct btrfs_root *root,
void __user *arg)
ret = -EFAULT;
goto out;
}
- vol_args-name[BTRFS_PATH_NAME_MAX] = '\0';
+ vol_args-name[BTRFS_VOL_NAME_MAX] = '\0';
ret = btrfs_rm_device(root, vol_args-name);
out:
diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index b320b10..f5d182a 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h
@@ -22,12 +22,10 @@
#define BTRFS_IOCTL_MAGIC 0x94
#define BTRFS_VOL_NAME_MAX 255
-#define BTRFS_PATH_NAME_MAX 4087
-/* this should be 4k */
struct btrfs_ioctl_vol_args {
__s64 fd;
- char name[BTRFS_PATH_NAME_MAX + 1];
+ char name[BTRFS_VOL_NAME_MAX + 1];
};
struct btrfs_ioctl_clone_range_args {
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index db9fb3b..5facdbf 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -593,7 +593,7 @@ static long btrfs_control_ioctl(struct file *file, unsigned
int cmd,
ret = -EFAULT;
goto out;
}
- len = strnlen(vol-name, BTRFS_PATH_NAME_MAX);
+ len = strnlen(vol-name, BTRFS_VOL_NAME_MAX);
switch (cmd) {
case BTRFS_IOC_SCAN_DEV:
--
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: use BTRFS_VOL_NAME_MAX for struct btrfs_ioctl_vol_args
On Mon, Jan 19, 2009 at 08:57:32PM +0800, Américo Wang wrote: I found userspace tool, btrfsctl, uses BTRFS_VOL_NAME_MAX, and it also looks that this one is more proper. Kill BTRFS_PATH_NAME_MAX since no one will use it. Nope, BTRFS_PATH_NAME_MAX is specifically used for the ioctl stuff, makes the arguments 4k aligned, this patch is incorrect. Thanks, Josef -- 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] btrfsctl.c: fix the definition of struct btrfs_ioctl_vol_args
According to the definition in kernel space, this one should be changed.
Signed-off-by: WANG Cong wangc...@zeuux.org
---
diff --git a/btrfsctl.c b/btrfsctl.c
index e049799..5ff7f69 100644
--- a/btrfsctl.c
+++ b/btrfsctl.c
@@ -39,7 +39,7 @@
#define BLKGETSIZE64 0
#define BTRFS_IOC_SNAP_CREATE 0
#define BTRFS_VOL_NAME_MAX 255
-struct btrfs_ioctl_vol_args { char name[BTRFS_VOL_NAME_MAX]; };
+struct btrfs_ioctl_vol_args { char name[BTRFS_VOL_NAME_MAX+1]; int fd;};
static inline int ioctl(int fd, int define, void *arg) { return 0; }
#endif
--
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] bit-radix.c: fix declarations
bit-radix.c should #include bit-radix.h, and add a missing declaration for find_next_bit(). Signed-off-by: WANG Cong wangc...@zeuux.org --- diff --git a/bit-radix.c b/bit-radix.c index 57f6f3c..01bf4af 100644 --- a/bit-radix.c +++ b/bit-radix.c @@ -17,7 +17,7 @@ */ #include kerncompat.h -#include radix-tree.h +#include bit-radix.h #define BIT_ARRAY_BYTES 256 #define BIT_RADIX_BITS_PER_ARRAY ((BIT_ARRAY_BYTES - sizeof(unsigned long)) * 8) diff --git a/bit-radix.h b/bit-radix.h index af14e80..ff82c9c 100644 --- a/bit-radix.h +++ b/bit-radix.h @@ -23,6 +23,8 @@ int set_radix_bit(struct radix_tree_root *radix, unsigned long bit); int test_radix_bit(struct radix_tree_root *radix, unsigned long bit); int clear_radix_bit(struct radix_tree_root *radix, unsigned long bit); +unsigned long find_next_bit(const unsigned long *addr, unsigned long size, +unsigned long offset); int find_first_radix_bit(struct radix_tree_root *radix, unsigned long *retbits, unsigned long start, int nr); -- 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] btrfsck.c: bit-fields should be unsigned
bit-fields should be unsigned.
Signed-off-by: WANG Cong wangc...@zeuux.org
---
diff --git a/btrfsck.c b/btrfsck.c
index 4a41e6d..1bf4064 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -60,10 +60,10 @@ struct extent_record {
struct inode_backref {
struct list_head list;
- int found_dir_item:1;
- int found_dir_index:1;
- int found_inode_ref:1;
- int filetype:8;
+ unsigned int found_dir_item:1;
+ unsigned int found_dir_index:1;
+ unsigned int found_inode_ref:1;
+ unsigned int filetype:8;
int errors;
u64 dir;
u64 index;
@@ -83,13 +83,13 @@ struct inode_backref {
struct inode_record {
struct list_head backrefs;
- int checked:1;
- int found_inode_item:1;
- int found_dir_item:1;
- int found_file_extent:1;
- int found_csum_item:1;
- int some_csum_missing:1;
- int nodatasum:1;
+ unsigned int checked:1;
+ unsigned int found_inode_item:1;
+ unsigned int found_dir_item:1;
+ unsigned int found_file_extent:1;
+ unsigned int found_csum_item:1;
+ unsigned int some_csum_missing:1;
+ unsigned int nodatasum:1;
int errors;
u64 ino;
--
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] btrfs-progs: make several functions static
Make several functions static, and make one argument const.
Signed-off-by: WANG Cong wangc...@zeuux.org
---
diff --git a/btrfsck.c b/btrfsck.c
index 4a41e6d..c50de7d 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -1254,7 +1254,7 @@ static int fs_root_objectid(u64 objectid)
return 0;
}
-int check_fs_roots(struct btrfs_root *root)
+static int check_fs_roots(struct btrfs_root *root)
{
struct btrfs_path path;
struct btrfs_key key;
@@ -1937,7 +1937,7 @@ static int add_root_to_pending(struct extent_buffer *buf,
return 0;
}
-int check_extent_refs(struct btrfs_root *root,
+static int check_extent_refs(struct btrfs_root *root,
struct cache_tree *extent_cache)
{
struct extent_record *rec;
@@ -1972,7 +1972,7 @@ int check_extent_refs(struct btrfs_root *root,
return err;
}
-int check_extents(struct btrfs_root *root)
+static int check_extents(struct btrfs_root *root)
{
struct cache_tree extent_cache;
struct cache_tree seen;
@@ -2057,7 +2057,7 @@ int check_extents(struct btrfs_root *root)
return ret;
}
-void print_usage(void)
+static void print_usage(void)
{
fprintf(stderr, usage: btrfsck dev\n);
fprintf(stderr, %s\n, BTRFS_BUILD_VERSION);
diff --git a/btrfsctl.c b/btrfsctl.c
index e049799..6891d66 100644
--- a/btrfsctl.c
+++ b/btrfsctl.c
@@ -43,7 +43,7 @@ struct btrfs_ioctl_vol_args { char name[BTRFS_VOL_NAME_MAX];
};
static inline int ioctl(int fd, int define, void *arg) { return 0; }
#endif
-void print_usage(void)
+static void print_usage(void)
{
printf(usage: btrfsctl [ -d file|dir] [ -s snap_name subvol|tree ]\n);
printf([-r size] [-A device] [-a] [-c]\n);
@@ -59,7 +59,7 @@ void print_usage(void)
exit(1);
}
-int open_file_or_dir(char *fname)
+static int open_file_or_dir(const char *fname)
{
int ret;
struct stat st;
--
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] Fix tree logs parallel sync
Hello,
To improve performance, btrfs_sync_log merges tree log sync
requests. But it wrongly merges sync requests for different
tree logs. If multiple tree logs are synced at the same time,
only one tree log, only one of them actually gets synced.
This patch has following changes to fix the bug.
Move most tree log related fields in btrfs_fs_info to
btrfs_root. This allows merging sync requests separately
for each tree log.
Don't insert root item into the log root tree immediately
after log tree is allocated. Root item for log tree is
inserted when log tree get synced for the first time. This
allows syncing the log root tree without first syncing all
log trees.
At tree-log sync, btrfs_sync_log first sync the log tree;
then updates corresponding root item in the log root tree;
sync the log root tree; finally updates the super block.
Signed-off-by: Yan Zheng zheng@oracle.com
---
diff -urp 1/fs/btrfs/ctree.h 2/fs/btrfs/ctree.h
--- 1/fs/btrfs/ctree.h 2009-01-06 22:20:42.801117041 +0800
+++ 2/fs/btrfs/ctree.h 2009-01-19 15:42:02.0 +0800
@@ -701,9 +701,7 @@ struct btrfs_fs_info {
struct btrfs_transaction *running_transaction;
wait_queue_head_t transaction_throttle;
wait_queue_head_t transaction_wait;
-
wait_queue_head_t async_submit_wait;
- wait_queue_head_t tree_log_wait;
struct btrfs_super_block super_copy;
struct btrfs_super_block super_for_commit;
@@ -730,10 +728,6 @@ struct btrfs_fs_info {
atomic_t async_submit_draining;
atomic_t nr_async_bios;
atomic_t async_delalloc_pages;
- atomic_t tree_log_writers;
- atomic_t tree_log_commit;
- unsigned long tree_log_batch;
- u64 tree_log_transid;
/*
* this is used by the balancing code to wait for all the pending
@@ -833,7 +827,14 @@ struct btrfs_root {
struct kobject root_kobj;
struct completion kobj_unregister;
struct mutex objectid_mutex;
+
struct mutex log_mutex;
+ wait_queue_head_t log_writer_wait;
+ wait_queue_head_t log_commit_wait[2];
+ atomic_t log_writers;
+ atomic_t log_commit[2];
+ unsigned long log_transid;
+ unsigned long log_batch;
u64 objectid;
u64 last_trans;
diff -urp 1/fs/btrfs/disk-io.c 2/fs/btrfs/disk-io.c
--- 1/fs/btrfs/disk-io.c2009-01-06 22:20:42.805117060 +0800
+++ 2/fs/btrfs/disk-io.c2009-01-19 15:42:02.0 +0800
@@ -850,6 +850,14 @@ static int __setup_root(u32 nodesize, u3
spin_lock_init(root-list_lock);
mutex_init(root-objectid_mutex);
mutex_init(root-log_mutex);
+ init_waitqueue_head(root-log_writer_wait);
+ init_waitqueue_head(root-log_commit_wait[0]);
+ init_waitqueue_head(root-log_commit_wait[1]);
+ atomic_set(root-log_commit[0], 0);
+ atomic_set(root-log_commit[1], 0);
+ atomic_set(root-log_writers, 0);
+ root-log_batch = 0;
+ root-log_transid = 0;
extent_io_tree_init(root-dirty_log_pages,
fs_info-btree_inode-i_mapping, GFP_NOFS);
@@ -934,15 +942,16 @@ int btrfs_free_log_root_tree(struct btrf
return 0;
}
-int btrfs_init_log_root_tree(struct btrfs_trans_handle *trans,
-struct btrfs_fs_info *fs_info)
+static struct btrfs_root *alloc_log_tree(struct btrfs_trans_handle *trans,
+struct btrfs_fs_info *fs_info)
{
struct btrfs_root *root;
struct btrfs_root *tree_root = fs_info-tree_root;
+ struct extent_buffer *leaf;
root = kzalloc(sizeof(*root), GFP_NOFS);
if (!root)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
__setup_root(tree_root-nodesize, tree_root-leafsize,
tree_root-sectorsize, tree_root-stripesize,
@@ -951,12 +960,23 @@ int btrfs_init_log_root_tree(struct btrf
root-root_key.objectid = BTRFS_TREE_LOG_OBJECTID;
root-root_key.type = BTRFS_ROOT_ITEM_KEY;
root-root_key.offset = BTRFS_TREE_LOG_OBJECTID;
+ /*
+* log trees do not get reference counted because they go away
+* before a real commit is actually done. They do store pointers
+* to file data extents, and those reference counts still get
+* updated (along with back refs to the log tree).
+*/
root-ref_cows = 0;
- root-node = btrfs_alloc_free_block(trans, root, root-leafsize,
- 0, BTRFS_TREE_LOG_OBJECTID,
- trans-transid, 0, 0, 0);
+ leaf = btrfs_alloc_free_block(trans, root, root-leafsize,
+ 0, BTRFS_TREE_LOG_OBJECTID,
+ trans-transid, 0, 0, 0);
+ if (IS_ERR(leaf)) {
+ kfree(root);
+ return ERR_CAST(leaf);
+ }
+ root-node = leaf;
Re: Warning and BUG with btrfs and corrupted image
On Tue 2009-01-13 15:43:07, Eric Sesterhenn wrote: * Chris Mason (chris.ma...@oracle.com) wrote: On Tue, 2009-01-13 at 15:21 +0100, Eric Sesterhenn wrote: Hi, when mounting an intentionally corrupted btrfs filesystem i get the following warning and bug message. The image can be found here www.cccmz.de/~snakebyte/btrfs.2.img.bck.bz2 Thanks for looking at things Aside from catching checksumming errors, we're not quite ready for fuzzer style attacks. The code will be hardened for this but it isn't yet. Does this mean i should stop trying to break it for now or are you interested in further reports? Does ext2/3 and vfat survive that kind of attacks? Those are 'in production' and should survive it... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning
On Tue, Jan 20, 2009 at 08:01:52AM +1100, Linus Torvalds wrote: On Mon, 19 Jan 2009, Nick Piggin wrote: I want to know what is the problem with the restrict keyword? I'm sure I've read Linus ranting about how bad it is in the past... No, I don't think I've ranted about 'restrict'. I think it's a reasonable solution for performance-critical code, and unlike the whole type-aliasing model, it actually works for the _sane_ cases (ie doing some operation over two arrays of the same type, and letting the compiler know that it can access the arrays without fearing that writing to one would affect reading from the other). The problem with 'restrict' is that almost nobody uses it, and it does obviously require programmer input rather than the compiler doing it automatically. But it should work well as a way to get Fortran-like performance from HPC workloads written in C - which is where most of the people are who really want the alias analysis. OK, that makes sense. I just had a vague feeling that you disliked it. it seems like a nice opt-in thing that can be used where the aliases are verified and the code is particularly performance critical... Yes. I think we could use it in the kernel, although I'm not sure how many cases we would ever find where we really care. Yeah, we don't tend to do a lot of intensive data processing, so it is normally the cache misses that hurt most as you noted earlier. Some places it might be appropriate, though. It might be nice if it can bring code size down too... -- 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: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning
The problem with 'restrict' is that almost nobody uses it, and it does Also gcc traditionally didn't do a very good job using it (this might be better in the very latest versions). At least some of the 3.x often discarded this information. automatically. But it should work well as a way to get Fortran-like performance from HPC workloads written in C - which is where most of the people are who really want the alias analysis. It's more than just HPC -- a lot of code has critical loops. it seems like a nice opt-in thing that can be used where the aliases are verified and the code is particularly performance critical... Yes. I think we could use it in the kernel, although I'm not sure how many cases we would ever find where we really care. Very little I suspect. Also the optimizations that gcc does with this often increase the code size. While that can be a win, with people judging gcc's output apparently *ONLY* on the code size as seen in this thread[1] it would obviously not compete well. -Andi [1] although there are compilers around that generate smaller code than gcc at its best. -- a...@linux.intel.com -- Speaking for myself only. -- 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: Warning and BUG with btrfs and corrupted image
Hi, * Pavel Machek (pa...@suse.cz) wrote: On Tue 2009-01-13 15:43:07, Eric Sesterhenn wrote: * Chris Mason (chris.ma...@oracle.com) wrote: On Tue, 2009-01-13 at 15:21 +0100, Eric Sesterhenn wrote: Hi, when mounting an intentionally corrupted btrfs filesystem i get the following warning and bug message. The image can be found here www.cccmz.de/~snakebyte/btrfs.2.img.bck.bz2 Thanks for looking at things Aside from catching checksumming errors, we're not quite ready for fuzzer style attacks. The code will be hardened for this but it isn't yet. Does this mean i should stop trying to break it for now or are you interested in further reports? Does ext2/3 and vfat survive that kind of attacks? Those are 'in production' and should survive it... I regularly (once or twice a week) test 100 corrupted images of vfat, udf, msdos, swap, iso9660, ext2, ext3, ext4, minix, bfs, befs, hfs, hfs+, qnx4, affs and cramfs on each of my two test machines. They are all pretty stable, one remaining thing on my list i didnt have time to look into was an issue with fat (msdos) triggering a bug in buffer.c the other is a warning with ext4 in jbd2/checkpoint.c:166 If there is a filesystem you are interested in thats not on the list or that you want me to test a bit more, just let me know Greetings, Eric -- 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
