[Kos-dev] "Race condition" 1

[Thomas Petazzoni]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD8B33A9139E8D35D4B908296
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hello,

> J'avoue ne pas avoir trop d'idées pour ce bug.

Finalement, j'ai une idée. Avec d2, on a supposé que quand un thread
déjà lancé redémarrait son éxécution, c'était forcément  dans
cpl0_switch_with_return, ce qui est totalement faux !

cpl0_switch_with_return n'est utilisé que par les fonctions
kwaitqueue_add_(sleeping|waiting), c'est à dire quand un thread bloque
sur une sémaphore.

Dans le cas "normal", c'est le handler de l'IRQ timer qui appelle
reschedule_after_interrupt, qui retourne le nouveau cpu_state au hanlder
d'IRQ, qui se charge de restaurer le contexte. Et la, au moment du IRET,
clairement les interruptions redeviennent actives, et on ne passe pas du
tout par cpl0_switch_with_return.

J'ai peut être tort, ou bien cela n'a rien à voir avec le bug, mais en
tout cas, ça me semble bizarre.

Finalement, je me demande pourquoi ma solution initiale (appeler
cpl0_delete_pending_thread depuis cpl0_switch_no_return_internal juste
après le switch de pile, mais avant de restaurer le contexte) est mauvaise.

Thomas
-- 
PETAZZONI Thomas - thomas DOT petazzoni AT enix DOT org - UIN : 34937744
Web: http://www.enix.org/~thomas/
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

--------------enigD8B33A9139E8D35D4B908296
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+1HGP9lPLMJjT96cRAnGqAKC4SSMHziU3HCgq3ap167Kq+iw++gCgxiD2
5sBpEmCrDVUZx0nE9570vwU=
=UiTO
-----END PGP SIGNATURE-----

--------------enigD8B33A9139E8D35D4B908296--