[Kos-dev] Anonymous : pas si facile que ca

[d2]

Bonjour,

Le probleme, c'est de savoir si une autre virtual region que celle de
team fautif est concernee. C'est ca ? Histoire de mettre a jour tous
les address-spaces *concernes* a jour, et seulement ceux-la ? Le
probleme etant alors d'identifier ces address-spaces reellement
/concernes/. En lisant ton mail rapidement, je pensais que tu te
posais le pb de reconnaitre les liens entre teams, savoir lesquels
sont les teams concernes... peut-etre en s'inspirant des liens de
parente.

Je pense pas que ca doive etre tres fin. Si je me souviens bien de nos
tests mmap() qu'on avait menes, on remarquait que si 1 processus A
mappait /foobar en SHARED d'un cote, et qu'un autre processus B (avec
OU sans aucun lien de parente) mappait lui-aussi /foobar en SHARED, on
voyait que B voyait les modifs faites par A. Ce qui suggere que des
qu'il y a SHARED des 2 cote, et des que les zones du fichier mappe se
recouvrent, il y a partage des pages physiques. Donc si la sr est
mappee dans A avec la virtual_region VA, dans B avec VB, C/VC, D/VD,
tels que VA=VB=V1, VC=VD=V2 (en terme de pointeur vers
shadow_resource, resource_offset et de longeur de virtual_region
seulement), si un #PF arrive pour A dans VA, alors la sr regarde
quelles virtual regions en SHARED recouvrent l'offset resource ou il y
a eu le #PF => elle trouve seulement VB, et donc ne s'interesse qu'a
mapper la page dans B.

En MAP_SHARED, ca doit etre un truc comme ca :

ON pgflt upon MAP_SHARED shadow_resource at vaddr for virtual_region
VR:

    offset_in_resource = VR.resource_offset + vaddr - VR.node.key;
    ppage = get_phys_page()
    for (virtual region _vr associee a la ressource (listes vr_(not_)alone_in_pt_list)
         AVEC _vr.sharing_type == MAP_SHARED
         AVEC _vr.resource_offset <= offset_in_resource < _vr.resource_offset + (_vr.end - _vr.node.key))
      {
        map ppage a l'adresse _vr.node.key + (offset_in_resource - _vr.resource_offset) dans la team de _vr
      }
    appel methode map() de la shadow_resource a l'adresse vaddr

Je pense que le cas mmap(/dev/null) est un peu atypique et ne repose
pas sur une shadow ressource unique globale au systeme. De mon point
de vue, a chaque fois qu'un team mmap(/dev/null), ca cree une nouvelle
shadow resource speciale dedicace pour le team qui fait le mmap. Qd ce
mapping est shared, c'est cette shadow resource nouvellement allouee
qui est partagee entre pere et fils (pluriel), et le mecanisme
ci-dessus s'applique sur cette nouvelle sr. Qd c'est un fichier autre
que /dev/null, la par contre, il y' a bien 1 seule shadow ressource
pour tout le systeme, et le mecanisme ci-dessus s'applique (partage
des memes pages physiques meme si les 2 processus n'ont aucun lien de
parente).

Qd c'est du MAP_PRIVATE par contre, ca doit juste rajouter 1 etape :
tant que c'est des #PF en read, on mappe la shadow_resource comme
ci-dessus. Des le 1er #PF en write, on supprime la sr pour la
remplacer par une sr type /dev/null ("anonymous"), et on n'agit plus
que sur celle-ci (en ne recreant pas une sr /dev/null au prochain #PF
write bien sur).

La subtilite, ca doit etre de faire que le mmap(/dev/null) alloue une
nouvelle shadow_ressource. Et pas pour le reste (fichiers, devices,
...).

Voila mon point de vue, fortement inspire de la norme posix. Reste a
savoir si cette norme nous convient.

Bonne journee,

-- 
d2