[SOS] sos: au sujet de defauts d'initialisation

[guerineau]

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

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