Re: Repeatable ext4 oops with 3.6.0 (regression)

[Theodore Ts'o <tytso@mit.edu>]

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>