> > child->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?
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
