[SOS] sos: au sujet de defauts d'initialisation; ATTENTION: patch initial incorrect

[guerineau]

Je me suis aperçu d'une erreur dans la patch que je viens d'envoyer l'erreur
concerne la modification sur le fichier blkcache.c"). Voici le patch
corrigé.
C. Guerineau

----- Original Message -----
From: guerineau <chris.guer at wanadoo.fr>
To: anthoine.bourgeois <anthoine.bourgeois at wanadoo.fr>; SOS mailing-list
<sos at the-doors.enix.org>
Sent: Saturday, November 24, 2007 7:54 AM
Subject: Re: [SOS] sos: au sujet de defauts d'initialisation


> Donc , le patch ainsi qu' une note de synthese des modifications.
> Le patch comporte des modifications (de nommage essentiellement) par
rapport
> a ce qui etait annoncé dans mon message initial. J'ai ajoute egalement une
> correction d'initialisation concernant le module fs_fat (puisque le
probleme
> concernait tous les file system).
> C. Guerineau
>
> ----- Original Message -----
> From: anthoine.bourgeois <anthoine.bourgeois at wanadoo.fr>
> To: SOS mailing-list <sos at the-doors.enix.org>
> Sent: Monday, November 19, 2007 3:27 PM
> Subject: Re: [SOS] sos: au sujet de defauts d'initialisation
>
>
> Bonjour,
>
> Merci Guerineau pour tes recherches. Je sais qu'on a tous les éléments
pour
> le faire mais pourrais-tu nous faire un patch de toutes tes anomalies
> trouvées dans SOS? On pourra certainement l'intégrer dans la prochine
> version de SOS.
>
> Merci d'avance,
> Anthoine
>
> > Message du 18/11/07 13:11
> > De : "guerineau" <chris.guer at wanadoo.fr>
> > A : sos at the-doors.enix.org
> > Copie à :
> > Objet : [SOS] sos: au sujet de defauts d'initialisation
> >
> > 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.
> >
> > 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.
> >
> > Il me semble donc utile de les communiquer:
> >
> > Anomalie constatee:
> >
> > A. Initialisation incorrecte de variables statiques:
> >
> > ====================================================
> >
> > Dans "certaines conditions" , certaines variables supposees initialisees
> ne le sont pas.
> >
> > Exemple:
> >
> > - fs.c: fs_list
> >
> > - uaccess.c : __uaccess_zero_fool_gcc
> >
> > - mm_context.c: current_mm_context et list_mm_context
> >
> > - process.c: process_list (non applicable a la version 10)
> >
> >
> >
> > 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.
> >
> > Dans "certaines conditions", ce fait est dramatique.
> >
> > Par exemple:
> >
> > - fs_virtfs.c: structure virtfs_type
> >
> > - chardev.c : registered_chardev_classes
> >
> > - blkdev.c : registered_blockdev_instances
> >
> > 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.
> >
> >
> >
> > Le linkeur place toutes ces variables apres la borne __e_load. Cette
borne
> est definie de maniere a englober les sections ".data" et ".rodata".
> >
> > Nos variables fautives ne sont donc pas placees dans aucune de ces deux
> sections.
> >
> > Elles echappent ainsi a l'initialisation realisee par le processus de
> chargement du noyau (qui arrete le chargement a la borne __e_load).
> >
> > 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.
> >
> >
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > De mon coté, j'ai ajoute des instructions explicites d'initialisation
dans
> les fonctions d'initialisation de chaque module, quand ceci etait
possible:
> >
> > Voir details dans l'annexe.
> >
> > B. Defaut d'initialisation d'une structure allouee dynamiquement
> >
> > ================================================================
> >
> > 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.
> >
> > Correction suggeree:
> >
> > ...
> >
> > blkcache
> >
> > = (struct sos_block_cache*) sos_kmalloc(sizeof(struct sos_block_cache),
> 0);
> >
> > if (NULL == blkcache)
> >
> > return NULL;
> >
> > --> 3 lignes ajoutees:
> >
> > list_init(blkcache->free_list);
> >
> > list_init(blkcache->sync_list);
> >
> > list_init(blkcache->dirty_list);
> >
> > ...
> >
> > C. Guerineau
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Annexe:
> >
> > =======
> >
> > Code introduit en contournement des problemes d'initailisation de
> variables statiques:
> >
> > - blkdev.c
> >
> > sos_blockdev_subsystem_setup()
> >
> > list_init(registered_blockdev_instances)
> >
> > - fs_virtfs.c
> >
> > sos_ret_t sos_fs_virtfs_subsystem_setup()
> >
> > struct sos_fs_manager_type *type = &virtfs_type;
> >
> > memset(type,0, sizeof(*type));
> >
> > - process.c (pour version 9_5 maxi)
> >
> > sos_ret_t sos_process_subsystem_setup()
> >
> > list_init(process_list);
> >
> > 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:
> >
> > Par exemple:
> >
> > - fs.c:
> >
> > void fs_presetup()
> >
> > {
> >
> > list_init(fs_list);
> >
> > }
> >
> > - mm_context.c
> >
> > void sos_mm_context_subsystem_pre_setup()
> >
> > {
> >
> > list_init(list_mm_context);
> >
> > current_mm_context = NULL;
> >
> > }
> >
> > Remarque:
> >
> > Cette variable -list_mm_context- fait l'objet d'une initialisation via
la
> >
> > fonction idoine sos_mm_context_subsystem_setup(). Cependant, cette
> initialisation
> >
> > arrive trop tard car , et comme le souligne son auteur, cette variable
est
> utilisee
> >
> > via des appels de fonction sos_paging_map declenchés AVANT cette
> initialisation.
> >
> > - uaccess.c
> >
> > void uaccess_setup(void)
> >
> > {
> >
> > __uaccess_zero_fool_gcc = 0;
> >
> > }
> >
> > - chardev.c:
> >
> > void chardev_setup()
> >
> > {
> >
> > list_init(registered_chardev_classes);
> >
> > }
> >
> >
> >
> >
> >
> > [ (pas de nom de fichier) (0.1 Ko) ]
>
> _______________________________________________
> Sos mailing list
> Sos at the-doors.enix.org
> http://the-doors.enix.org/cgi-bin/mailman/listinfo/sos
>
>


----------------------------------------------------------------------------
----


_______________________________________________
Sos mailing list
Sos at the-doors.enix.org
http://the-doors.enix.org/cgi-bin/mailman/listinfo/sos

-------------- section suivante --------------
Un texte encapsulé et encodé dans un jeu de caractères inconnu a été nettoyé...
Nom : patch_sos_10_p1_2.txt
Url : http://the-doors.enix.org/pipermail/sos/attachments/20071124/3d173815/attachment-0001.txt