I am 100% sure. I can look at the disassembly, and point to the fact that
your Oops happens on code that is simply totally bogus.
That string is NUL-terminated, which is why the access is to f2a3fffe in
the first place: we explicitly asked d_path() to create us a string at the
end of the page (it creates them backwards), so the path string has a NUL
a the end at address f2a3ffff, which is exactly what we'd expect.
Your compiler really does seem to be total crap.
Do a "make fs/seq_file.s" (and make sure you *disable* CONFIG_DEBUG_INFO
first, otherwise the result will be unreadable crud), and look at
seq_path(). It's going to be more readable than the disassembly that I got
through gdb, but I bet it's going to show it even more clearly.
.. of *course* DEBUG_PAGEALLOC is going to be implied in the problem. If
you don't have DEBUG_PAGEALLOC, you'll never see this, because you'll have
all pages mapped, and the only page that it could happen to is the very
last page in memory, and you'll never hit that one in practice.
It's not about "possible". It's a fact. Send me your "seq_file.s" output
for that function to be sure - it *could* be memory corruption that
changes a "movb" into a "movl", and maybe the compiler did a byte move to
start with, but quite frankly, that is such a remote possibility that I
don't consider it realistic.
This looks like *exactly* the same thing, except you're in
"show_vfsmnt()" this time.
Again: the oopsing instruction (8b 3a) is "movl". And again, the address
is f6206ffe, and it oopses because the (incorrect) 32-bit access will
touch the next page, so you get a paging request fault on f6207000 - which
is some *totally* different allocation, and one that isn't mapped because
it doesn't exist, so DEBUG_PAGE_ALLOC has removed it.
.. and again: exact same thing.
.. and again:
And I can even tell you exactly what path it is:
- it's going to be the first path that shows up in the path list, since
the seq_file interface will re-use that page, so if you hit it, you'll
hit it on the first entry (unless seq_file has *lots* of data and needs
more than a single-page allocation)
- it must be a single-byte path, because otheriwse you'd have oopsed one
byte earlier (you'd have oopsed already on access .....ffd, which would
*also* overflow to the next page
- ergo, it's "/".
but that doesn't really even matter. Disassembling the code stream from
your oops shows clearly that it's a 32-bit access. No ifs, buts or maybes
about it. If you don't trust the gdb disassembly (I didn't, entirely, so I
looked it up) byte 0x8b is "mov Gv,Ev" in the Intel opcode map.
A 8-bit move would have been 0x8a.
Linus
-
