[Kos-dev] "Race condition" 1

[d2]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas> Voila pour mes expérimentations de la soirée. Qu'en
    Thomas> pensez-vous ?

En ce qui me concerne, j'en pense que "la verite est ailleurs"... Si
j'ai bien suivi ton enquete, une interruption apparait entre un
switch_no_return (on verifie pourtant qu'un gos cli a ete fait) et la
fin d'un switch_with_return (or eflags est /normalement/ tel que IE
est 0). Si c'est le cas, c'est qu'y'a un truc qui nous a echappe dans
les specs Intel. Ou sinon c'est qu'on active les interruptions par
erreur sans nous en apercevoir (=> tester eflags au plus profond dans
l'asm). Ou alors que l'interpretation est a approfondir encore (avec
des bochs_printk non intrusifs par exemple). Tes ASSERT me semblent
vraiment tres bien places, mais le premier doute qui me viendrait
serait qu'on fait malgre ca un truc bizarre avec le flag IE sans nous
en rendre compte.

Ou alors une histoire d'optimisation de gcc a la con ; rajouter
volatile sur thread_to_be_destoyed pour etre sur (GROS ENOOOORMES
doutes). Ou une histoire de cache sur cette variable.

La, il est tard et je suis fatigue, je peux dfficilement creuser le
probleme, mais c'est pour le moins intriguant. Cependant, c'est la
voie "rajouter un cmp thread_to_be_destroyed, $0\nje 1f\n1: jb 1b" que
j'explorerais (c'est du pseudo assembleur on va dire).

Ceci dit, dans ces cas la, mets ton test qui fait bugger sur le CVS,
et ta proposition de correction.

A la semaine prochaine !

-- 
d2