Linus Torvalds wrote:I've seen a lot of people who don't know too much assembler just work based on the RIP. As in look it up in the source using addr2line or gdb and then try to figure it out based on the source. Actually looking at the register contents and how the instruction uses it is pretty arcane knowledge and usually not even needed. And with more and more kernel developers being newbie friendly in this area is a good thing. How about if the page fault handler checks for the value and prints a obvious string? It could do this reliably, unlike the "grep all registers for poison on #GP" method that was earlier proposed. I discussed this with Avi earlier and we were careful to put it into one of the guaranteed to be unmapped holes. This should actually not change if the CPU changes because it's defined by the kernel mapping. If these holes ever change the poison would need to change too, but otherwise I don't really see how it should be particularly unreliable. Ok it might break if someone messes up the direct mapping, but if that happens you typically don't even go through the oops handler completely and won't see the message. -Andi --
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| Linus Torvalds | Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes g... |
git: | |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Ray Lee | Re: [BUG] New Kernel Bugs |
