Hi folks! Here's today's status of the utrace work. The current trees fork from v2.6.26, which came out over the weekend.
Note there are 2.6.26/ directories of patches and GIT branches, but those are not yet to be used. For the moment, the upstream tip is still 2.6.26 and so the "tip" utrace branches (2.6-current/ patches) are what to use for that and I might not have the 2.6.26/ always up to date. Some day soon, the upstream tip will diverge from 2.6.26 and then I will start worrying about the backport branch properly. The latest code is the newest Fedora Rawhide kernel build (2.6.26-137.fc10). The Rawhide tree and mirrors might take another day to pick it up, but you can always download from koji.fedoraproject.org directly. I have dealt with all the x86 arch issues (single-step stuff). I've changed the syscall report interface as just posted about here. I've made PTRACE_SYSEMU work using that, and UML is happy with it (on x86-32 and x86-64, running a 32-bit UML binary). The ptrace-tests 'make check' suite has no FAILs. I implemented the missing vfork-done event support for CONFIG_UTRACE_PTRACE=y. I can't say it's thoroughly tested. But the XXX hole there before was responsible for the WARN_ON output (easily mistaken in logs for an oops/crash) showing up every time you used gdb. Note that there is a kernel crash when running the GDB test suite. The crash I got was from a use-after-free in disassociate_ctty. This manifested as "general protection fault" on a memory-access instruction where the address it tried to use was 0x6b6b6b6b... (the 6b is the debug kernel's after-free poison byte value). I also got this crash running the same GDB test suite setup on a vanilla 2.6.26 build on the same machine (i.e. everything the same except none of my kernel patches). So currently I believe this is not related to utrace (or even ptrace), but is just an unhappy coincidence of a new problem in the pty code or something that gets tickled by using expect in dejagnu. BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ for a kernel-vanilla build I did of 2.6.26. If you have any problems with the rawhide kernel, you can compare the behavior of this kernel to sort out my bugs from upstream bugs. (I have not tried that RPM nor the Rawhide kernel RPMs lately. All the testing I mentioned above is with my hand-built upstream development kernels.) Thanks, Roland
