btrfs: fix search key advancing condition (dd81d459) · Commits · 戴 / test

The search key advancing condition used in copy_to_sk() is loose. It can advance the key even if it reaches sk->max_*: e.g. when the max key = (512, 1024, -1) and the current key = (512, 1025, 10), it increments the offset by 1, continues hopeless search from (512, 1025, 11). This issue make ioctl() to take unexpectedly long time scanning all the leaf a blocks one by one. This commit fix the problem using standard way of key comparison: btrfs_comp_cpu_keys() Signed-off-by:

Naohiro Aota <naota@elisp.net> Reviewed-by:

Filipe Manana <fdmanana@suse.com> Signed-off-by:

Chris Mason <clm@fb.com>

fs/btrfs/ioctl.c

+9 −3

Original line number	Diff line number	Diff line
		@@ -1933,6 +1933,7 @@ static noinline int copy_to_sk(struct btrfs_root *root,
		u64 found_transid;
		struct extent_buffer *leaf;
		struct btrfs_ioctl_search_header sh;
		struct btrfs_key test;
		unsigned long item_off;
		unsigned long item_len;
		int nritems;
		@@ -2016,12 +2017,17 @@ static noinline int copy_to_sk(struct btrfs_root *root,
		}
		advance_key:
		ret = 0;
		if (key->offset < (u64)-1 && key->offset < sk->max_offset)
		test.objectid = sk->max_objectid;
		test.type = sk->max_type;
		test.offset = sk->max_offset;
		if (btrfs_comp_cpu_keys(key, &test) >= 0)
		ret = 1;
		else if (key->offset < (u64)-1)
		key->offset++;
		else if (key->type < (u8)-1 && key->type < sk->max_type) {
		else if (key->type < (u8)-1) {
		key->offset = 0;
		key->type++;
		} else if (key->objectid < (u64)-1 && key->objectid < sk->max_objectid) {
		} else if (key->objectid < (u64)-1) {
		key->offset = 0;
		key->type = 0;
		key->objectid++;

Admin message