Possbile bug in hashtable.S : add_hash_page

[Paul Mackerras]

Bob Doiron writes:

> However - r1 remains unchanged within the function. As it stands, it seems
> that an interrupt could come along and scrible on our return address by
> using the unchanged stack pointer. What I've been seeing is that when under

No - if an interrupt happens, it should decrement the stack pointer
before writing to the stack.  An interrupt should never modify
anything at or above the current stack pointer.

> heavy interrupt load (nfs mount kernel compile for example) my ppc gets
> stuck in a "here: jump here" loop right at the blr instruction listed above.
> Inspecting the stack @ 4(r1) showed that it did in fact have the address of
> the blr instruction there, which led me to beleive that it is getting
> corrupted by an interrupt. Simply changing the "4" offset in 4(r1) to 12
> makes for a rock stable kernel, but it's a horrific hack.

Well, it might be getting corrupted by an interrupt, in which case the
most likely cause is some code using a local array variable and
accessing outside the bounds of the array.  It's hard to see what that
code would be doing to put the address of the blr in that word of
memory though.

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/