BUG: Global FPU corruption in 2.2
Quoted 6 lines · Linus Torvalds
Ahh.. This actually _does_ look like a race on "
current->flags":PTRACE_ATTACHwill do achild->flags |= PF_PTRACED;without waiting for the child to have stopped.
I can see how this could case PF_USEDFPU to be cleared inadvertently, but I do not have any ideas for testing this. Is it clear that this is the source of the problem?
What would be involved in backporting the split ptrace flags to 2.2? Are there other solutions?
Vic
Quoted 7 lines
Quoted 3 lines
child->flags |= PF_PTRACED;without waiting for the child to have stopped.
I can see how this could case
PF_USEDFPUto be cleared inadvertently, but I do not have any ideas for testing this. Is it clear that this is the source of the problem?
There is no guarantee that |= is implemented atomically - in fact its quite likely to read
get child->flags or PF_PTRACED write child->flags
and a PF_USEDFPU on another processor at the same instant -would- end up being lost.
There are two fixes
1. Make all the ops atomic (foo_bit())
2. Split the flags
The preferable one for performance is certainly to backport the 2.4 changes
Quoted 1 line · Alan Cox
The preferable one for performance is certainly to backport the 2.4 changes
Is it any more substantial than changing all uses of the ptrace flags to the new variable?
Quoted 5 lines
Quoted 1 line · Alan Cox
The preferable one for performance is certainly to backport the 2.4 changes
Is it any more substantial than changing all uses of the ptrace flags to the new variable?
It affects asm blocks and offsets on some ports. Its not too bad tho