I've not actually seen truncate_inode_pages' "I goofed!" message
(except when I added further debug to cover lstart != 0 truncation,
which fsx is keen on), but I think it could occur even in that case.
It seems that __lookup() can easily return 0, even though there's
more to find, if it starts partway into a RADIX_TREE_MAP_SIZE
array, in which the only occupied slots are before it starts.
Patch below seems to fix it, but I bet you can improve upon it.
Might this relate to Trond/Chuck's NFS invalidation woes?
It's certainly the main contributor to my tmpfs problems.
I look forward to your "erk" - or will you delight us with
some other exclamation?!
--- 2.5.36-mm1/lib/radix-tree.c Tue Sep 17 11:04:08 2002
+++ linux/lib/radix-tree.c Wed Sep 18 19:46:10 2002
@@ -231,8 +231,6 @@ __lookup(struct radix_tree_root *root, v
unsigned int height = root->height;
struct radix_tree_node *slot;
- if (index > max_index)
- return 0;
shift = (height-1) * RADIX_TREE_MAP_SHIFT;
slot = root->rnode;
@@ -307,9 +305,11 @@ radix_tree_gang_lookup(struct radix_tree
unsigned int nr_found;
unsigned long next_index; /* Index of next search */
+ if (cur_index > max_index)
nr_found = __lookup(root, results + ret, cur_index,
max_items - ret, &next_index, max_index);
- if (nr_found == 0)
+ if (nr_found == 0 && !(cur_index & RADIX_TREE_MAP_MASK))
ret += nr_found;
cur_index = next_index;
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:24 EST