On Thu, Oct 04, 2012 at 05:31:41PM +0200, Holger Hoffstätte wrote: > So armed with multiple running shells I finally managed to save the dmesg > to NFS. It doesn't get any more complete than this and again shows the > ext4 stacktrace from before. So maybe it really is generic kmem corruption > and ext4 looking at symlinks/inodes is just the victim. That certainly seems to be the case. As near as I can tell from the stack trace, you're doing a readdir(), and the crash is happening in ext4_htree_store_dirent() --- the stack address to ext4_follow_link() makes no sense given the rest of the strack trace, and anyway, ext4_follow_link() doesn't do any memory allocation. So that means this: > [ 106.643048] [<c0236ed9>] ext4_htree_store_dirent+0x29/0x110 Almost certainly corresponds to the following call to kzalloc: /* Create and allocate the fname structure */ len = sizeof(struct fname) + dirent->name_len + 1; new_fn = kzalloc(len, GFP_KERNEL); dirent->name_len is a unsigned char, and struct fname is around 48 bytes or so. So len is never going to be larger than 300 bytes, and never smaller than 48 bytes, which is certainly valid input as far as kzalloc() is concerned. So it's very likely that the crash in __kmalloc() is probably caused by the internal slab/slub data structures getting scrambled. Regards, - Ted -- 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
