[pso] Situatie de race la tema 1

Maximilian Machedon maximilian.machedon at gmail.com
Sat Mar 25 08:17:52 EET 2006


    Apar probleme, cu sanse mai mari pe sisteme multiprocesor (oricum,
sansele sunt mici). Sa zicem ca pe doua procesoare se incepe monitorizarea
pentru cate un pid diferit; checking_pid o sa fie in mod incorect facut 0 de
prima rutina care intra in al doilea spinlock.
Cred, in schimb, ca daca faci checking_pid++ si checking_pid-- s-ar putea sa
fie corect.  Alta problema este ca unul dintre cele doua apeluri de
monitorizare ar putea sa nu intre in al doilea spinlock pana cand celalalt
goleste coada. Uite o varianta bazata pe ideea ta, care pare "mai corecta",
dar nu garantez :-)

START_MONITOR:

---8<---------------------------

spinlock_acquire()
checking_pid++;
//poate merge cu un "atomic increment" (?)
//caz in care se modifica si mai jos verificarile si decrementarea
spinlock_release()

check_pid();

spinlock_acquire()
checking_pid--;
if (list_find(exited_pids, pid))
    pid_is_invalid = true;
    //nu am voie sa-l elimin, poate mai are cineva nevoie de el
else
    can_monitor_pid
if (checking_pid == 0)
    list_clear(exited_pids);
spinlock_release()

---8<--------------------------- 


La process exit:
---8<--------------------------- 

spinlock_acquire()
if (checking_pid != 0)
    list_append(exited_pids, this_pid)
spinlock_release()

---8<-----------------

        Singura problema este ca sistemul devine mai usor atacabil pe
multiprocesor (teoretic; practic cred ca e greu/imposibil de realizat): un
utilizator rau intentionat ar putea sa "omoare" kernelul umpland lista de
procese: face multe cereri de monitorizari pentru propriile procese, pe care
le omoara foarte repede. Lista ar putea ajunge sa nu fie niciodata golita
(din nou, teoretic). Scenariul este: pe N/2 procesoare (sa zicem) se fac
cereri de monitorizare pentru un pid care va ramane valid, doar pentru a
mentine contorul tot timpul peste 0; pe celelalte procesoare se creeaza si
se omoara multe procese. Eventual nici nu ocupa toate procesoarele, doar X
ca sa mentina contorul peste 0 + unul pentru creat si omorat procese.

        Si mai am o intrebare (am mai intrebat ceva asemanator): daca un
proces face un apel de sistem si moare intre timp, ce pateste stiva kernel a
procesului (si apelul in curs de executie), cand dispare? Cand returneaza
apelul de sistem?





----- Original Message ----- 
From: Bogdan Harjoc
To: Proiectarea Sistemelor de Operare
Sent: Friday, March 24, 2006 8:48 PM
Subject: Re: [pso] Situatie de race la tema 1

Probabil e ceva gresit si la "solutia" asta ... in fine:

In my_syscall(), cand primesti REQUEST_START_MONITOR:

---8<---------------------------
spinlock_acquire()
checking_pid = 1;
list_clear(exited_pids);
spinlock_release()

check_pid();

spinlock_acquire()
checking_pid = 0;
if (list_find(exited_pids, pid))
    pid_is_invalid();
...

---8<--------------------------- 

In rutina de tratare a exit-ului:
spinlock_acquire()
if (checking_pid)
    list_append(exited_pids, this_pid)
spinlock_release()

---8<-----------------



More information about the pso mailing list