The fix works! Sorta!
If I execute the 'crash' program it just gets an invalid opcode..
If I make a shell script start off multiple crash programs in paralell the
machine quickly locks hard (no console actvitiy, on magicsysrq, just like
the non-patched lockup).. So its a big improvement, but it's not prefect..
At this level seems to eliminate the possibility of network explotiable
overflows using this bug..
There is my old report:
On Thu, 13 Nov 1997, linux kernel account wrote:
>
> System:
> Dual 166MMX Tyan Tomcat-IIID.
> 64megs, SCSI.. Lotsa config options.
>
> Opon execution of the F00F crash program, the computer still crashes.
> HOWEVER, the previous crash was a complete hard lock, this one allowed
> console interaction.
>
> Magic-sysrequest showed that the 'bash' that had forked off the 'Process
> of Doom' was stuck as 'current' process.
>
> An improvement, but not quite yet. I would guess that, softdog could have
> rebooted the computer in this case..
>
> Maby some SMP lock isn't being acquired by the handler.
>
> Minor nitpick: The bug report in /proc/cpuinfo needs tab correction.
>