avoid fc5 kernels > kernel-2.6.17-1.2187_FC5 and < 1.2243

avoid fc5 kernels > kernel-2.6.17-1.2187_FC5 and < 1.2243

[Roland McGrath]

I just discovered today that recent fc5 kernel updates are basically the
fc6 kernel rebuilt, including the utrace patch (and no doubt some
intermediate buggy version to boot).  I've been recommending "the FC5
kernel" as the stable reference kernel using the old pre-utrace ptrace.
Recent updates are no good for that purpose and should be avoided.

kernel-2.6.17-1.2187_FC5 is the last fc5 updates rpm before the updates
started including buggy utrace code.  For known-stable ptrace, please use
that for now or an earlier kernel that worked for you (my workstation has
been up for 41 days and it's running 2.6.17-1.2174_FC5).

I've asked the Fedora kernel maintainer to drop the utrace patch from fc5
update kernels, and the next update to go out will go back to the vanilla
upstream ptrace (may be a few days).  The safe update will have a version
higher than 2.6.18-1.2243.


Thanks,
Roland

Re: avoid fc5 kernels > kernel-2.6.17-1.2187_FC5 and < 1.2243

[Mark Wielaard]

Hi,

On Thu, 2006-11-16 at 23:51 -0800, Roland McGrath wrote:
> I just discovered today that recent fc5 kernel updates are basically the
> fc6 kernel rebuilt, including the utrace patch (and no doubt some
> intermediate buggy version to boot).  I've been recommending "the FC5
> kernel" as the stable reference kernel using the old pre-utrace ptrace.
> Recent updates are no good for that purpose and should be avoided.
> 
> kernel-2.6.17-1.2187_FC5 is the last fc5 updates rpm before the updates
> started including buggy utrace code.  For known-stable ptrace, please use
> that for now or an earlier kernel that worked for you (my workstation has
> been up for 41 days and it's running 2.6.17-1.2174_FC5).

Oops. I should have read and remembered this earlier. But just to
confirm that I am running 2.6.17-1.2174_FC5 now and on x86 it passes all
make check test. On x86_64 (multi-processor) there were 5 failures:

1)
testExecSyscall(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: inSyscall

This seems to be because it is a multi-processor and our detection of
whether or not we are in a syscall is flawed.

2)
testMultiThreadedDetached(frysk.util.TestFStack)junit.framework.AssertionFailedError: Task #5733
#0 0x3375d2f33f in __sigsuspend ()
[...]
did not match: (Task #\d+\n#0 0x[\da-f]+ in __kernel_vsyscall \(\)\n#1
[..]

3)
testMultiThreadedAckDaemon(frysk.util.TestFStack)junit.framework.AssertionFailedError: 4) testStressMultiThreadedDetach(frysk.util.TestFStack)junit.framework.AssertionFailedError: 5) testClone(frysk.util.TestFStack)junit.framework.AssertionFailedError: 

These seem to have checks which are too strict and match the call stack
as it is seen on x86, but not on x86_64. Is anyone else seeing these
pass or fail on something !x86?

Cheers,

Mark

Re: avoid fc5 kernels > kernel-2.6.17-1.2187_FC5 and < 1.2243

[Stan Cox]

On Tue, 2006-11-21 at 18:24 +0100, Mark Wielaard wrote:

> 1) testExecSyscall(frysk.proc.TestTaskSyscallObserver)
> 2) testMultiThreadedDetached(frysk.util.TestFStack)
> 3) testMultiThreadedAckDaemon(frysk.util.TestFStack)
> 4) testStressMurysk.util.TestFStack)
> 5) testClone(frysk.util.TestFStack)
> Is anyone else seeing these pass or fail on something !x86?

results using kernel 2.6.17-1.2174_FC5 on a dual Intel(R) Xeon(TM) 

Running testLinuxIa32(frysk.proc.TestSyscallsWithAudit) ...FAIL
Running testLinuxPPC(frysk.proc.TestSyscallsWithAudit) ...FAIL
Running testLinuxPPC64(frysk.proc.TestSyscallsWithAudit) ...FAIL
Running testLinuxX86_64(frysk.proc.TestSyscallsWithAudit) ...FAIL
Running testMultiThreadedDetached(frysk.util.TestFStack) ...FAIL
Running testMultiThreadedAckDaemon(frysk.util.TestFStack) ...FAIL
Running testStressMultiThreadedDetach(frysk.util.TestFStack) ...FAIL
Running testClone(frysk.util.TestFStack) ...FAIL

Re: avoid fc5 kernels > kernel-2.6.17-1.2187_FC5 and < 1.2243

[Mark Wielaard]

Hi Stan,

On Tue, 2006-11-21 at 15:20 -0500, Stan Cox wrote:
> On Tue, 2006-11-21 at 18:24 +0100, Mark Wielaard wrote:
> 
> > 1) testExecSyscall(frysk.proc.TestTaskSyscallObserver)

This one seems not deterministic although it fails most of the time for
me. This is http://sourceware.org/bugzilla/show_bug.cgi?id=3244

> Running testLinuxIa32(frysk.proc.TestSyscallsWithAudit) ...FAIL
> Running testLinuxPPC(frysk.proc.TestSyscallsWithAudit) ...FAIL
> Running testLinuxPPC64(frysk.proc.TestSyscallsWithAudit) ...FAIL
> Running testLinuxX86_64(frysk.proc.TestSyscallsWithAudit) ...FAIL

These do pass for me on a similar system. What version of libaudit do
you have? $ rpm -q audit-libs
audit-libs-1.2.9-1.fc5
audit-libs-1.2.9-1.fc5
(Apparently I have both the i386 and x86_64 versions installed)

> Running testMultiThreadedDetached(frysk.util.TestFStack) ...FAIL
> Running testMultiThreadedAckDaemon(frysk.util.TestFStack) ...FAIL
> Running testStressMultiThreadedDetach(frysk.util.TestFStack) ...FAIL
> Running testClone(frysk.util.TestFStack) ...FAIL

So these are common failures for x86_64, but not on x86. FStack probably
tries to match the call stack precisely to what is generated on x86.

Cheers,

Mark