[Kos-dev] Re: [Kos-cvs] [kos] Modification CVS par d2

[d2]

Hello,

Quelques nouvelles. D'abord, apres investigation, le prbobleme du
spinlock est bien... un probleme de spinlock. Il peut etre
effectivement observe qd bcp de RAM dispo, mais aussi qd on alloue
suffisamment de pages.  Plus precisement, en realite, ce bug est lie a
une recusrivite sur rmap. En gros, quand le slab de rmap est au bout,
et qu'il s'agit de l'elargir, il s'agit d'allouer quelques pages, et
donc d'allouer d'autres rmap. Ce qui fait qu'au final, avant d'avoir
les nouveaux rmap, on demande a allouer d'autres rmap. Donc, outre les
pbs de lock en l'etat, ce genre de recursivite mene a une boucle
infinie (=> debordement de pile si on avait pas mis les check de
spinlock je pense). La seule solution que je vois pour l'instant,
c'est de prevoir une marge de quelques rmap quand on declenche
l'elargissement du slab : comme ca, quand l'elargissement a lieu, on a
suffisamment de rmap en reserve pour mapper l'elargissement. Le
probleme qui suivra, c'est encore un probleme de lock : il va bien
falloir faire gaffe a appeler le kvalloc pour l'elargissement en
dehors des locks style lock de cache/kvalloc. Ce qui risque de
soulever quelques problemes de race conditions (famine possible en
SMP). La vraie bonne solution que je vois, c'est d'utiliser des
semaphores values, mais ca sera pour plus tard.

Au fait, pourquoi ce bug apparait qd on a bcp de RAM seulement (ou qd
les gpfme sont plus gros, ie qd BUG_PMM est active) ? Parce que dans
ce cas on a besoin de bcp de gpfme, ce qui entraine des allocs de
rmap. Et forcement, on a toutes les chances dans ce cas d'arriver au
cas pathologique ou il faut etendre le slab de rmap. La 2eme question,
c'est pourquoi on peut avoir un triple fault ? La je sais pas encore.

Sinon, j'ai verifie, et toutes les zones init/modules/stack bootstrap
sont protegees qd on lance l'init pmm. Donc pas de bug de ce cote.

Bon, j'y travaille.

-- 
d2