On Monday, 21 of April 2008, Linus Torvalds wrote: > > 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? Sure, I have SLUB_DEBUG on already, rebooting with "slub_debug". Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
