* mm gang: you goofed!
@ 2002-09-18 19:28 Hugh Dickins
2002-09-18 20:17 ` Andrew Morton
0 siblings, 1 reply; 2+ messages in thread
From: Hugh Dickins @ 2002-09-18 19:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
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?!
Hugh
--- 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)
+ break;
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))
break;
ret += nr_found;
cur_index = next_index;
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: mm gang: you goofed!
2002-09-18 19:28 mm gang: you goofed! Hugh Dickins
@ 2002-09-18 20:17 ` Andrew Morton
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2002-09-18 20:17 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linux-kernel
Hugh Dickins wrote:
>
> ...
> 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.
erk. That sounds right.
I don't think the max_index test matters much - if we ever
hit that index then something has gone horridly wrong, because
it's out-of-bounds for the tree height. But whatever.
> Patch below seems to fix it
But your patch only fixes the symptoms of the bug. You should
fix the real bug. But to do that you'd need to find me, so this
will have to do for now.
> but I bet you can improve upon it.
Well the colour scheme is a bit gaudy.
> Might this relate to Trond/Chuck's NFS invalidation woes?
Nope; this code is only in the mm crash-test-dummy tree at present.
And it's currently at the "wow, it worked first time" stage. I need
to get down and write some special test code for it, and to run
fsx-linux. Possibly fsx-linux has sufficient coverage.
> It's certainly the main contributor to my tmpfs problems.
Sorry about that.
> I look forward to your "erk" - or will you delight us with
> some other exclamation?!
gack?
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-09-18 20:12 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-18 19:28 mm gang: you goofed! Hugh Dickins
2002-09-18 20:17 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox