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

[guerineau]

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/20071117/f49d2305/attachment.html