[Kos-dev] [BUG] Deadlock

[Thomas Petazzoni]

Salut,

Et oui les bugs de deadlock ca commence. Et avec la memoire, je pense
qu'on a pas fini.

J'expose le probleme, et ensuite je propose ma solution.

Le probleme
-----------

arch_map_virtual_page et arch_unmap_virtual_page font des locks sur
kernel_space_lock, afin d'etre sur de ne pas se marcher dessus lors de
la modification des PDs et PTs de la zone noyau. Or dans ce lock, je
dois faire un add_rmapping (si on est dans map) ou un del_rmapping (si
on est dans unmap). Le probleme est que la gestion des reverse mapping
(add et del) dependent de kslab.

Et kslab, pour agrandir/desagrandir les caches il a (indirectement)
besoin de la fonction arch_get_paddr_at_vaddr, pour retrouver le slab
courant (qui est stocke dans le GPFME). Et evidemment cette fonction
prend le kernel_space_lock, en read. Mais on est deja dans arch_map,
ou arch_unmap qui ont le lock => DEADLOCK.

Clairement le probleme vient du fait qu'on couche basse (arch/mm)
utilise une couche haute (kmem). Que cette couche haute depende de la
couche basse, c'est normal, mais l'inverse non.

Les solutions
-------------

1. Mettre les del_rmapping et add_rmapping en dehors des
   kernel_space_lock. Mais j'ai reflechi, cela n'est pas possible. En
   effet si on demappe la page (au niveau des PD, PT), qu'on libere le
   lock (avant de virer le reverse mapping) et qu'on se choppe une
   interruption (possible car on n'a plus le lock). Par le plus grand
   des hasards, le swapper est appelle, et encore une fois par le plus
   grand des hasards, c'est justement la page qu'on etait en train de
   demapper qu'il choisit de swapper. Il parcourt la liste des reverse
   mapping pour marquer la page comme non presente et swappee. Puisque
   le reverse mapping pour notre page virtuelle est toujours la, bin
   le swapper va marquer. Et notre page se retrouve de nouveau
   mappee... On pourrait solutionner le truc en codant le swapper avec
   beaucoup d'attention (verifiant que le PTE n'est pas 0 meme si le
   reverse mapping est la). Mais c'est long (au niveau temps
   processeur), et de toute facon avoir arch/mm qui depend de kmem
   c'est crade. On avait deja du modifier kslab pour qu'il alloue des
   la creation du cache un slab, pour que les reverse mapping ca
   marche bien.

2. Coder un allocateur de reverse mapping au niveau de arch/mm. On
   allouerai completement en dehors de la zone noyau des pages
   specifiquement pour les reverse mappings. Ainsi on pourrait avoir
   de 512M a 768M la zone noyau, puis de 768M a 1G la zone reverse
   mapping (c'est grand, mais autant voir grand !). Et cet allocateur
   sera present au niveau de arch/mm et fonctionnerait avec des
   bitmaps. En fait il marcherait exactement comme (ou presque) kslab,
   sauf qu'etant code au niveau de arch/mm, il pourra utiliser des
   fonctions unsafe.

Ma solution preferee est donc la deuxieme, mais avant de coder ce truc
j'aimerais avoir votre avis sur ce probleme.

Bonne soiree,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
(Perso)      http://www.enix.org/~thomas/
(KOS)        http://kos.enix.org/ 
(Club LinUT) http://club-linut.enix.org