On Wed, 3 Oct 2007, Ingo Molnar wrote: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 -
| Fred . | Please add ZFS support (from GPL sources) |
| Kristen Carlson Accardi | Re: PCIe Hotplug: NFG unless I boot with card already inserted. |
| Linus Torvalds | Re: [GIT]: Networking |
| Chuck Ebbert | Why do so many machines need "noapic"? |
git: | |
| Petr Baudis | Re: Cogito: cg-clone doesn't like packed tag objects |
| Andreas Ericsson | Re: [PATCH] git-merge: add option --no-ff |
| Junio C Hamano | GIT 0.99.6 |
| Wayne Scott | git-diff-tree rename detection bug |
| Unix Fan | Re: Vulnerability Note VU#800113 - Multiple DNS implementations vulnerable to cach... |
| Edd Barrett | Iwi, wireless bad behavior |
| jose thomas | Resume - Mumps Developer |
| Girish Venkatachalam | Ethernet jumbo frames? |
| der Mouse | Re: mjf-devfs2 branch |
| Ian Zagorskih | POSIX timer_settime() dosn't set timer in some cases (lost accuracy) |
| Christos Zoulas | Re: Melting down your network [Subject changed] |
| Gregory McGarry | Re: Lock benchmarks |
