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

[Romain LABBE]

Salut Guerineau,
 
Sacré dianostique, je pense que cela va grandement aider a stabiliser le
noyau
Je suis pas le mieux placé mais merci pour cet effort
 
A++
 
Romain

-----Message d'origine-----
De : sos-bounces at the-doors.enix.org [mailto:sos-bounces at the-doors.enix.org]
De la part de guerineau
Envoyé : samedi 17 novembre 2007 20:07
À : sos at the-doors.enix.org
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);

}

 

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: http://the-doors.enix.org/pipermail/sos/attachments/20071119/07a8be2d/attachment.htm