On Sun, Dec 16, 2012 at 2:40 PM, Matt Fleming <matt.flem...@intel.com> wrote:
>
> Linus have you got a stacktrace for the oops (and maybe even a dmesg)? I
> suspect it won't tell us much, but any/all info we can gather will help.
Sadly, it starts scrolling away pretty quickly, and it really wasn't
very useful. None of the traces contained any of the new code.
The backtrace was something like "find_vma()" called by "do_munmap()".
I do have a phone picture of an earlier oops, which was similar. In
that case, the oops happened in "unmap_single_vma()", with the call
trace being
unmap_vmas
exit_mmap
mmput
do_exit
do_group_exit
get_signal_to_deliver
do_signal
do_notify_resume
retint_signal
which looks rather similar: it's some kind of nasty vma list
corruption. The main difference being that the exit of the process
happened as a result of a signal rather than just a plain exit()
system call. Which is probably in turn the result of some corruption
of user-space data structures.
In some other cases, I've got quickly scrolling stuff that I couldn't
even guess at, or just a hung system at early boot.
> At this point, I'm wondering if insert_identity_mapping() is trashing
> valid mappings.
It does feel like *major* data corruption. As in "not just a bitflip
or two", but "megabytes of data is wrong".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
