Re: 2.6.25-git2: BUG: unable to handle kernel paging request at ffffffffffffffff

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, 20 Apr 2008, Paul E. McKenney wrote:
> 
> And it passes.

Ok, I applied it, with hopefully an understandable commit message.

That said, now we just need to figure out what actually caused the bug in 
question.

Rafael: if it's a too-early free of the dentry (which could be because 
somebody didn't do a proper rcu read-lock, or maybe the rcu grace period 
logic itself got broken?), then enabling SLUB/SLAB debugging should catch 
it much more quickly (and hopefully we'd see the signature of a 
use-after-free - the poisoning byte pattern rather than the -1).

The other alternative is simply memory corruption. Ie the -1 may well be 
somebody *else* overwritin the ->next pointer because they did a 
use-after-free and maybe the dentry_cache is shared with some other 
allocation of the same size (SLUB does that, no?)

Rafael: your last oops does seem to imply that there is some strange 
memory corruption going on, because in that case the invalid pointer is 
different: instead of being all-ones, it is "fff0810023444c98", which is 
not a possible pointer. It very much looks like a single nybble got 
cleared (because ffff810023444c98 _would_ be a valid pointer, notice the 
"fff0" vs "ffff" prefix).

So I do suspect it's *some* kind of use-after-free thing. But nothing in 
fs/ has changed, so it's not a dentry bug, I think. Which is why my 
"preferred" suspect is that "somebody else also does allocations of the 
same size as the dentry code, and shares the same SLUB alloc space, and 
does something bad".

So Rafael - are you using SLUB, and if you are, can you enable SLUB_DEBUG, 
and then use the "slub_debug" kernel command line to enable it?

			Linus