<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.6000.16544" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=265091613-19112007><FONT face=Arial color=#0000ff size=2>Salut
Guerineau,</FONT></SPAN></DIV>
<DIV><SPAN class=265091613-19112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=265091613-19112007><FONT face=Arial color=#0000ff size=2>Sacré
dianostique, je pense que cela va grandement aider a stabiliser le
noyau</FONT></SPAN></DIV>
<DIV><SPAN class=265091613-19112007><FONT face=Arial color=#0000ff size=2>Je
suis pas le mieux placé mais merci pour cet effort</FONT></SPAN></DIV>
<DIV><SPAN class=265091613-19112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=265091613-19112007><FONT face=Arial color=#0000ff
size=2>A++</FONT></SPAN></DIV>
<DIV><SPAN class=265091613-19112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=265091613-19112007><FONT face=Arial color=#0000ff
size=2>Romain</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=fr dir=ltr align=left><FONT face=Tahoma
size=2>-----Message d'origine-----<BR><B>De :</B>
sos-bounces@the-doors.enix.org [mailto:sos-bounces@the-doors.enix.org] <B>De
la part de</B> guerineau<BR><B>Envoyé :</B> samedi 17 novembre 2007
20:07<BR><B>À :</B> sos@the-doors.enix.org<BR><B>Objet :</B> [SOS]
sos: au sujet de defauts d'initialisation<BR><BR></FONT></DIV>
<DIV><FONT face="Courier New" size=2>
<P>Je pensais que SOS s'etait eteint d'une mort discrete. J'ai ete surpris
-agreablement- de constater , courant Octobre, qu'il etait toujours
vivant.</P>
<P>J'en profite pour rapporter deux classes d'incident que j'ai
essentiellement rencontrees au cours d'exploration de versions derivees de la
9_5. A l'analyse du code de la version 10, je constate que la plupart des
incidents sont encore applicables.</P>
<P>Il me semble donc utile de les communiquer:</P>
<P>Anomalie constatee:</P>
<P>A. Initialisation incorrecte de variables statiques:</P>
<P>====================================================</P>
<P>Dans "certaines conditions" , certaines variables supposees initialisees ne
le sont pas.</P>
<P>Exemple: </P>
<P>- fs.c: fs_list</P>
<P>- uaccess.c : __uaccess_zero_fool_gcc</P>
<P>- mm_context.c: current_mm_context et list_mm_context</P>
<P>- process.c: process_list (non applicable a la version 10)</P>
<P> </P>
<P>De plus, et inversement, certaines variables , dont l'etat doit etre tres
precis au demarrage et ne faisant l'objet d'aucune action d'initialisation
(que ce soit dans la declaration ou dans une procedure explicite) se
retrouvent dans un etat compatible avec celui attendu et ne perturbent en rien
le fonctionnement de SOS.</P>
<P>Dans "certaines conditions", ce fait est dramatique.</P>
<P>Par exemple:</P>
<P>- fs_virtfs.c: structure virtfs_type</P>
<P>- chardev.c : registered_chardev_classes</P>
<P>- blkdev.c : registered_blockdev_instances</P>
<P>Pour ces trois exemples, ces variables doivent imperativement etre
initialisee a zero. Ceci n'est pas fait, et , dans la plupart des cas, le
systeme fonctionne correctement.</P>
<P> </P>
<P>Le linkeur place toutes ces variables apres la borne __e_load. Cette borne
est definie de maniere a englober les sections ".data" et ".rodata". </P>
<P>Nos variables fautives ne sont donc pas placees dans aucune de ces deux
sections. </P>
<P>Elles echappent ainsi a l'initialisation realisee par le processus de
chargement du noyau (qui arrete le chargement a la borne __e_load).</P>
<P>l'outil "nm" renseigne que ces variables sont placees dans une section
'b'(ou 'B'), c'est a dire , non initialisee. Pour les variables ne faisant pas
l'objet d'une initialisation a la declaration, ce placement ne semble pas
aberrant. </P>
<P> </P>
<P>En examinant de pres le comportement de gcc, on constate qu'il traite de
maniere particuliere le placement des variables initialisees a zero: toutes
les variables ainsi initialisee sont placees dans une section placee au dela
de notre borne de chargement. En fait, dans une section ".bss". On peut alors
conjecturer que GCC compte sur le runtime pour initialiser la zone .bss a
zero. Nous en avons un exemple au sein meme de SOS: dans la section
"userland", la fonction de demarrage des taches (_start) commence en tout
premier a fixer a zero toute la zone bss. </P>
<P>Ce dysfonctionnement a ete constate sur un seul PC (sur les 3 uniques PCs
qui m'ont servi de test) et sur une version derivee de la 9.5.</P>
<P>Je pense donc que ,pour une raison que j'ignore (etat initial a zero,
initialisation explicite par le Bios ?), la memoire se trouve souvent dans un
etat compatible avec les attentes de SOS. Ceci n'est pas une raison pour
proposer une version de SOS plus robuste capable de resister a ce type d'alea
en corrigeant ce defaut dans l'initialisation.</P>
<P>De mon coté, j'ai ajoute des instructions explicites d'initialisation dans
les fonctions d'initialisation de chaque module, quand ceci etait
possible:</P>
<P>Voir details dans l'annexe.</P>
<P>B. Defaut d'initialisation d'une structure allouee dynamiquement</P>
<P>================================================================</P>
<P>Dans le fichier sos/blkcache.c et dans le cadre de la fonction
sos_blkcache_new_cache , les 3 pointeurs de liste de la structure
sos_block_cache ne sont pas initialises.</P>
<P>Correction suggeree:</P>
<P>...</P>
<P>blkcache</P>
<P>= (struct sos_block_cache*) sos_kmalloc(sizeof(struct sos_block_cache),
0);</P>
<P>if (NULL == blkcache)</P>
<P>return NULL;</P>
<P>--> 3 lignes ajoutees: </P>
<P>list_init(blkcache->free_list);</P>
<P>list_init(blkcache->sync_list);</P>
<P>list_init(blkcache->dirty_list);</P>
<P>... </P>
<P>C. Guerineau </P>
<P> </P>
<P> </P>
<P> </P>
<P> </P>
<P>Annexe:</P>
<P>=======</P>
<P>Code introduit en contournement des problemes d'initailisation de variables
statiques:</P>
<P>- blkdev.c</P>
<P>sos_blockdev_subsystem_setup()</P>
<P>list_init(registered_blockdev_instances)</P>
<P>- fs_virtfs.c</P>
<P>sos_ret_t sos_fs_virtfs_subsystem_setup()</P>
<P>struct sos_fs_manager_type *type = &virtfs_type;</P>
<P>memset(type,0, sizeof(*type));</P>
<P>- process.c (pour version 9_5 maxi)</P>
<P>sos_ret_t sos_process_subsystem_setup()</P>
<P>list_init(process_list);</P>
<P>Quand la fonction d'initialisation n'etait pas disponible ou que
l'initialisation devait se faire tres tot, des fonctions de "presetup" ont ete
utilisees. Elles doivent etre declenchees tres tot dans main.c:</P>
<P>Par exemple:</P>
<P>- fs.c: </P>
<P>void fs_presetup()</P>
<P>{</P>
<P>list_init(fs_list);</P>
<P>}</P>
<P>- mm_context.c</P>
<P>void sos_mm_context_subsystem_pre_setup()</P>
<P>{</P>
<P>list_init(list_mm_context);</P>
<P>current_mm_context = NULL;</P>
<P>}</P></FONT><FONT face="Courier New" size=2>
<P>Remarque:</P>
<P>Cette variable -list_mm_context- fait l'objet d'une initialisation via la
</P>
<P>fonction idoine sos_mm_context_subsystem_setup(). Cependant, cette
initialisation</P>
<P>arrive trop tard car , et comme le souligne son auteur, cette variable est
utilisee</P>
<P>via des appels de fonction sos_paging_map declenchés AVANT cette
initialisation. </P></FONT><FONT face="Courier New" size=2>
<P>- uaccess.c</P>
<P>void uaccess_setup(void)</P>
<P>{</P>
<P>__uaccess_zero_fool_gcc = 0;</P>
<P>}</P>
<P>- chardev.c:</P>
<P>void chardev_setup()</P>
<P>{</P>
<P>list_init(registered_chardev_classes);</P>
<P>}</P>
<P> </P></FONT></DIV></BLOCKQUOTE></BODY></HTML>