Laborator 7 - Memoria virtuală

• lab06-slides.pdf
• lab06-refcard.pdf

• TLPI - Chapter 49, Memory mappings
• TLPI - Chapter 50, Virtual memory operations

• Maparea fișierelor
• Alocare de memorie în spațiul de adresă al procesului
• Maparea dispozitivelor
• Demaparea unei zone din spațiul de adresă
• Redimensionarea unei zone mapate
• Schimbarea protecției unei zone mapate
• Blocarea paginării
• ElectricFence

Mecanismul de memorie virtuală este folosit de către nucleul sistemului de operare pentru a implementa o politică eficientă de gestiune a memoriei. Astfel, cu toate că aplicațiile folosesc în mod curent memoria virtuală, ele nu fac acest lucru în mod explicit. Există însă câteva cazuri în care aplicațiile folosesc memoria virtuală în mod explicit.

Sistemul de operare oferă primitive de mapare a fișierelor, a memoriei sau a dispozitivelor în spațiul de adresă al unui proces.

• Maparea fișierelor în memorie este folosită în unele sisteme de operare pentru a implementa mecanisme de memorie partajată. De asemenea, acest mecanism face posibilă implementarea paginării la cerere și a bibliotecilor partajate.
• Maparea memoriei în spațiul de adresă este folositoare atunci când un proces dorește să aloce o cantitate mare de memorie.
• Maparea dispozitivelor este folositoare atunci când un proces dorește să folosească direct memoria unui dispozitiv (precum placa video).

Dimensiunea spațiului de adresă virtual al unui proces depinde de dimensiunea registrelor procesorului. Astfel, pe un sistem de 32 biți un proces va putea accesa 2^32 = 4GB spațiu de memorie (pe de altă parte, pe un sistem de 64 biți va accesa teoretic 2^64 B). Spațiul de memorie al procesului este împărțit în spațiu rezervat pentru adresele virtuale de kernel - acest spațiu este comun tuturor proceselor - și spațiul virtual (propriu) de adrese al procesului. De cele mai multe ori, împărțirea între cele două este de 3/1 (3GB user space vs 1GB kernel space).

Memoria fizică (RAM) este împărțită între procesele active în momentul respectiv și sistemul de operare. Astfel că, în funcție de câtă memorie avem pe mașina fizică, este posibil să epuizăm toate resursele și să nu mai putem porni un proces nou. Pentru a evita acest scenariu s-a introdus mecanismul de memorie virtuală. În felul acesta, chiar dacă spațiul virtual (compus din segmentul de text, data, heap, stivă) al unui proces este mai mare decât memoria fizică disponibilă pe sistem, procesul va putea rula încărcându-și în memorie doar paginile de care are nevoie în timpul execuției (on demand paging).

Spațiul virtual de adrese este împărțit în pagini virtuale (page). Corespondentul pentru memoria fizică este pagina fizică (frame). Dimensiunea unei pagini virtuale este egală cu cea a unei pagini fizice. Dimensiunea este dată de hardware (în majoritatea cazurilor o pagină are 4KB pe un sistem de 32 biți sau 64 biți).

Atât timp cât un proces în timpul rulării accesează numai pagini rezidente în memorie, se execută ca și când ar avea tot spațiul mapat în memoria fizică. În momentul în care un proces va dori să acceseze o anumită pagină virtuală, care nu este mapată în memorie, se va genera un page fault, iar în urma acestui page fault pagina virtuală va fi mapată la o pagină fizică. Două procese diferite au spațiu virtual diferit, însă anumite pagini virtuale din aceste procese se pot mapa la aceeași pagină fizică. Astfel că, două procese diferite pot partaja o aceeași pagină fizică, dar nu partajează pagini virtuale.

Așa cum am aflat la laboratorul de gestiunea memoriei, malloc alocă memorie pe heap, deci în spațiul virtual al procesului. Funcția malloc poate fi implementată fie folosind apeluri de sistem brk, fie apeluri mmap (mai multe detalii găsiți aici). Despre funcția mmap vom vorbi în următoarele paragrafe din laboratorul curent.

Alocarea memoriei virtuale se face la nivel de pagină, astfel că malloc va aloca de fapt cel mai mic număr de pagini virtuale ce cuprinde spațiul de memorie cerut. Fie următorul cod:

char *p = malloc(4150);
DIE(p == NULL, "malloc failed");

Considerând că o pagină virtuală are 4KB = 4096 octeți, atunci apelul malloc va aloca 4096 octeți + 54 octeți = 4KB + 54 octeți, spațiu care nu este cuprins într-o singură pagină virtuală, astfel că se vor aloca 2 pagini virtuale. În momentul alocării cu malloc nu se vor aloca (tot timpul) și pagini fizice; acestea vor fi alocate doar atunci când sunt accesate datele din zona de memorie alocată cu malloc. De exemplu, în momentul accesării unui element din p se va genera un page fault, iar pagina virtuală ce cuprinde acel element va fi mapată la o pagină fizică.

În urma mapării unui fișier în spațiul de adresă al unui proces, accesul la acest fișier se poate face similar cu accesarea datelor dintr-un vector. Eficiența metodei vine din faptul că zona de memorie este gestionată similar cu memoria virtuală, supunându-se regulilor de evacuare pe disc atunci când memoria devine insuficientă (în felul acesta se poate lucra cu mapări care depășesc dimensiunea efectivă a memoriei fizice). Mai mult, partea de I/O este realizată de către kernel, programatorul scriind cod care doar preia/stochează valori din/în regiunea mapată. Astfel nu se mai apelează read, write, lseek - ceea ce adesea simplifică scrierea codului.

Prototipul funcției mmap ce permite maparea unui fișier în spațiul de adresă al unui proces este următorul:

void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);

Funcția va întoarce în caz de eroare MAP_FAILED. Dacă maparea s-a făcut cu succes, va întoarce un pointer spre o zonă de memorie din spațiul de adresă al procesului, zonă în care a fost mapat fișierul descris de descriptorul fd, începând cu offset-ul offset. Folosirea parametrului start permite propunerea unei anumite zone de memorie la care să se facă maparea. Folosirea valorii NULL pentru parametrul start indică lipsa vreunei preferințe în ceea ce privește zona în care se va face alocarea. Adresa precizată prin parametrul start trebuie să fie multiplu de dimensiunea unei pagini. Dacă sistemul de operare nu poate să mapeze fișierul la adresa cerută, atunci îl va mapa la o adresă apropiată și multiplu de dimensiunea unei pagini. Cea mai corespunzatoare adresa este si intoarsa.

Parametrul prot specifică tipul de acces care se dorește:

• PROT_READ (citire)
• PROT_WRITE (scriere)
• PROT_EXEC (execuție)
• PROT_NONE.

Cand zona e folosită altfel decât s-a declarat, este generat un semnal SIGSEGV.

Parametrul flags permite stabilirea tipului de mapare ce se dorește; poate lua următoarele valori (combinate prin SAU pe biți; trebuie să existe cel puțin MAP_PRIVATE sau MAP_SHARED):

• MAP_PRIVATE - Se folosește o politică de tip copy-on-write. Zona va conține inițial o copie a fișierului, dar scrierile nu sunt făcute în fișier. Modificările nu vor fi vizibile în alte procese, dacă există mai multe procese care au făcut mmap pe aceeași zonă din același fișier.
• MAP_SHARED - Scrierile sunt actualizate imediat în toate mapările existente. In acest fel toate procesele care au realizat mapări vor vedea modificările. Lucru datorat faptului că mapările MAP_SHARED se fac peste paginile fizice din page cache, iar apelurile r/w folosesc paginile fizice din page cache pentru a reduce numărul de citiri/scrieri de pe disc. Actualizările pe disc vor avea loc la un moment de timp ulterior, nespecificat.
• MAP_FIXED - Dacă nu se poate face alocarea la adresa specificată de start, apelul va eșua.
• MAP_LOCKED - Se va bloca paginarea pe această zonă, în maniera mlock.
• MAP_ANONYMOUS - Se mapează memorie RAM (argumentele fd și offset sunt ignorate).

Este de remarcat faptul că folosirea MAP_SHARED permite partajarea memoriei între procese care nu sunt înrudite. În acest caz, conținutul fișierului devine conținutul inițial al memoriei partajate și orice modificare făcută de procese în această zonă este copiată apoi în fișier, asigurând persistență prin sistemul de fișiere.

Pentru a declanșa în mod explicit sincronizarea fișierului cu maparea din memorie este disponibilă funcția msync:

int msync(void *start, size_t length, int flags);

unde flags poate fi:

• MS_SYNC - Datele vor fi scrise în fișier și se așteaptă până se termină.
• MS_ASYNC - Este inițiată secvența de salvare, dar nu se așteaptă terminarea ei.
• MS_INVALIDATE - Se invalidează mapările zonei din alte procese, astfel incât procesele își vor face update cu datele noi înscrise.

Apelul msync este util pentru a face scrierea paginilor modificate din page cache pe disc, cu scopul de a evita pierderea modificărilor în cazul unei căderi a sistemului.

În UNIX, tradițional, pentru alocarea memoriei dinamice, se folosește apelul de sistem brk. Acest apel crește sau descrește zona de heap asociată procesului. Odată cu oferirea către aplicații a unor apeluri de sistem de gestiune a memoriei virtuale (mmap), a existat posibilitatea ca procesele să aloce memorie folosind aceste noi apeluri de sistem. Practic, procesele pot mapa memorie în spațiul de adresă, nu fișiere.

Procesele pot cere alocarea unei zone de memorie de la o anumită adresă din spațiul de adresare, chiar și cu o anumită politică de acces (citire, scriere sau execuție). În UNIX, acest lucru se face tot prin intermediul funcției mmap. Pentru acest lucru parametrul flags trebuie să conțină flag-ul MAP_ANONYMOUS.

Există chiar și posibilitatea ca aplicațiile să mapeze în spațiul de adresă al unui proces un dispozitiv de intrare-ieșire. Acest lucru este util, de exemplu, pentru plăcile video: o aplicație poate mapa în spațiul de adresă memoria fizica a plăcii video. În UNIX, dispozitivele fiind reprezentate prin fișiere, pentru a realiza acest lucru nu trebuie decât să deschidem fișierul asociat dispozitivului și să-l folosim într-un apel mmap.

Un alt exemplu de dispozitiv care poate fi mapat este chiar memoria. În Linux se poate folosi fișierul /dev/zero pentru a face mapări de memorie, ca și când s-ar folosi flag-ul MAP_ANONYMOUS.

Dacă se dorește demaparea unei zone din spațiul de adresă al procesului se poate folosi funcția munmap:

 int munmap(void *start, size_t length);

start reprezintă adresa primei pagini ce va fi demapată (trebuie să fie multiplu de dimensiunea unei pagini). Dacă length nu este o dimensiune care reprezintă un număr întreg de pagini, va fi rotunjit superior. Zona poate să conțină bucăți deja demapate. Se pot astfel demapa mai multe zone în același timp.

Pentru a executa operații de redimensionare a zonei mapate se poate utiliza funcția mremap:

void *mremap(void *old_address, size_t old_size, size_t new_size, unsigned long flags);

Zona pe care old_address și old_size o descriu trebuie să aparțină unei singure mapări. O singură opțiune este disponibilă pentru flags: MREMAP_MAYMOVE care arată că este în regulă ca pentru obținerea noii mapări să se realizeze o nouă mapare într-o altă zonă de memorie (vechea zona fiind dealocată).

Uneori este nevoie ca modul (drepturile de acces) în care a fost mapată o zonă să fie schimbat. Pentru acest lucru se poate folosi funcția mprotect:

int mprotect(const void *addr, size_t len, int prot);

Funcția primește ca parametri intervalul de adrese [addr, addr + len - 1] și noile drepturi de access (PROT_READ, PROT_WRITE, PROT_EXEC, PROT_NONE). Ca și la munmap, addr trebuie să fie multiplu de dimensiunea unei pagini. Funcția va schimba protecția pentru toate paginile care conțin cel puțin un octet în intervalul specificat.

int fd = open("fisier", O_RDWR);
void *p = mmap(NULL, 2*getpagesize(), PROT_NONE, MAP_SHARED, fd, 0);
// *(char*)p = 'a'; // segv fault
mprotect(p, 2*getpagesize(), PROT_WRITE);
*(char*)p = 'a';
munmap(p, 2*getpagesize());

Apelul getpagesize va returna dimensiunea unei pagini in bytes.

Pentru ca sistemul de operare să poată implementa cât mai eficient accesele la o zona de memorie mapată, programatorul poate să informeze kernel-ul (prin apelul de sistem madvise) despre modul în care zona va fi folosită.

int madvise(void *start, size_t length, int advice);

Paginarea se referă la evacuarea paginilor pe disc (swap out) si restaurarea lor (swap in) atunci când sunt folosite. Există o categorie de procese care trebuie să execute anumite acțiuni la momente de timp bine determinate, pentru a se păstra calitatea execuției. Pentru exemplificare, putem considera un player audio/video sau un program ce controlează mersul unui robot biped. Problema cu acest gen de procese este dată de faptul că dacă o anumită pagină nu este prezentă în memorie, va dura un timp până ce ea va fi adusă de pe disc. Pentru a contracara aceste probleme, sistemele UNIX pun la dispoziție apelurile mlock și mlockall.

int mlock(const void *addr, size_t len);
int mlockall(int flags);

Există, bineînțeles, și funcții ce readuc lucrurile la normal:

int munlock(const void *addr, size_t len);
int munlockall(void);

Astfel, funcția munlock va reporni mecanismul de paginare al tuturor paginilor din intervalul [addr, addr + len - 1], iar funcția munlockall face același lucru pentru toate paginile procesului, atât curente, cât și viitoare. Trebuie notat faptul că, dacă s-au efectuat mai multe apeluri mlock sau mlockall, este suficient un singur apel munlock sau munlockall pentru a reactiva paginarea.

Atunci când se detectează o încălcare a protecției la accesul la memorie, se va trimite semnalul SIGSEGV sau SIGBUS procesului. După cum am văzut atunci când am discutat despre semnale, semnalul poate fi tratat cu două tipuri de funcții: sa_handler și sa_sigaction. Funcția de tip sa_sigaction va primi ca parametru o structură siginfo_t. În cazul semnalelor ce tratează excepții cauzate de un acces incorect la memorie, următoarele câmpuri din această structură sunt setate:

• si_signo - setat la SIGSEGV sau SIGBUS
• si_code - pentru SIGSEGV poate fi SEGV_MAPPER pentru a arăta că zona accesată nu este mapată în spațiul de adresă al procesului, sau SEGV_ACCERR pentru a arăta că zona este mapată dar a fost accesată necorespunzător; pentru SIGBUS poate fi BUS_ADRALN pentru a arăta că s-a făcut un acces nealiniat la memorie, BUS_ADRERR pentru a arăta că s-a încercat accesarea unei adrese fizice inexistente sau BUS_OBJERR pentru a indica o eroare hardware
• si_addr - adresa care a generat excepția

ElectricFence este un pachet ce ajută programatorii la depanarea problemelor de tipul buffer overrun. Aceste probleme sunt cauzate de faptul că anumite date sunt suprascrise fiindcă nu se fac verificări când se modifică date adiacente. Soluția folosită de Electric Fence este înlocuirea apelurilor standard malloc și free cu implementări proprii. Electric Fence va plasa zona de memorie alocată în spațiul de adrese al procesului, astfel încât ea să fie mărginită de pagini neaccesibile (protejate la scriere și citire).

Din păcate, sistemul de operare și arhitectura procesorului limitează dimensiunea paginii la cel puțin 1-4KB, astfel încât dacă zona de memorie alocată nu este multiplu de această dimensiune, există posibilitatea ca programul să poată citi sau scrie și în zone în care nu ar trebui, fără ca sistemul de operare să oprească executia programului. Pentru a preveni situații de acestă natură, Electric Fence alocă zonele de memorie la limita superioară a unei pagini, mapând o pagină neaccesibilă după aceasta. Această abordare nu previne buffer underrun-ul, în care datele sunt citite sau scrise sub limita inferioară.

Pentru a putea verifica și astfel de situații, utilizatorul trebuie să definescă variabila de mediu EF_PROTECT_BELOW înainte de rula programul. În acest caz, Electric Fence va plasa zona de memorie alocată la începutul unei pagini, pagină care la rândul ei este plasată după o pagină inaccesibilă procesului.

De ce este importantă detectarea situațiilor de buffer overrun? Așa cum am explicat și în secțiunea precedentă, astfel de situații vor produce în cele din urmă erori, dar la momente de timp ulterioare, când va fi mai greu să se determine cauza erorilor cu mijloace de depanare obișnuite. În plus, în situațiile de buffer overrun se pot suprascrie nu numai variabile, ci și alte date importante pentru stabilitatea programului cum ar fi datele de control folosite de rutinele malloc și free. Biblioteca Electric Fence poate determina erorile de buffer overrun doar dacă acestea apar în memoria alocată dinamic (adică în zona heap) cu rutinele malloc și free. Pentru a folosi Electric Fence utilizatorul trebuie să folosească la link-editare biblioteca libefence. Pentru a vedea utilitatea acestui pachet, să analizăm programul de mai jos:

ef_example.c

#include <stdio.h>
#include <malloc.h>
 
int main(void)
{
	int i;
	int *data_1, *data_2;
 
	data_1 = malloc(11 * sizeof(int));
 
	for (i = 0; i <= 11; i++)
		data_1[i] = i;
 
	data_2 = malloc(11 * sizeof(int));
 
	for (i = 0; i <= 11; i++)
		data_2[i] = 11 - i;
 
	for (i = 0; i <= 11; i++)
		printf("%d %d\n", data_1[i], data_2[i]);
 
	free(data_1); 
	free(data_2);
 
	return 0;
}

Aparent totul pare în regulă. La execuția programului însă obținem următorul output:

 so@spook$ gcc -Wall -g ef_example.c
 so@spook$ ./a.out
ff: malloc.c:3074: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) 
&((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) 
&& old_size == 0) || ((unsigned long)(old_size) >= (unsigned long)
((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t)))
 - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && 
((unsigned long)old_end & pagemask) == 0)' failed.

Ceva este clar în neregulă. Dacă folosim biblioteca libefence și GDB eroarea va fi vizibilă imediat:

 so@spook$ gcc -Wall -g ef_example.c -lefence
 so@spook$ gdb ./a.out 
 Reading symbols from /home/so/a.out...done.
 (gdb) run
 Starting program: /home/so/a.out 
 [Thread debugging using libthread_db enabled]
 
   Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
 
 Program received signal SIGSEGV, Segmentation fault.
 0x08048536 in main () at ef.c:12
 12			data_1[i] = i;
 (gdb) print i
 $1 = 11
 (gdb)

Se observă că eroarea apare în momentul în care încercăm să inițializăm al 12-lea element al vectorului, deși vectorul nu are decât 11 elemente.

Pentru mai multe informații despre Electric Fence consultați pagina de manual (man efence).

Pentru rezolvarea laboratorului, va rugam sa clonati repository-ul. daca il aveti deja, va rugam sa rulati git pull.

Intrați în directorul 1-intro și compilați sursa intro.c. Rulați programul intro:

./intro

Într-o altă consolă, folosiți comanda pmap.:

 watch -d pmap $(pidof intro)

pentru a urmări modificările asupra memoriei procesului.

În prima consolă, folosiți ENTER pentru a continua programul. În cea de-a doua consolă urmăriți modificările care apar în urma diferitelor tipuri de mapare din cod.

Analizați mapările făcute de procesul init folosind comanda:

sudo pmap 1

Intrați în directorul 2-compare și inspectați sursele write.c și mmap.c, apoi compilați. Obțineți timpul de execuție al celor două programe folosind comanda time:

time ./write; time ./mmap

Observăm că varianta cu mmap este mai rapidă decât varianta cu write. Vom folosi strace pentru a vedea ce apeluri de sistem se realizează pentru rularea fiecărui program:

strace -c ./write
strace -c ./mmap

Din output-ul strace observăm că programul write face foarte multe (100000) de apeluri write și din această cauză este mai lent decât programul mmap.

În continuare vom analiza cele două moduri de mapare a fișierelor: MAP_SHARED și MAP_PRIVATE. Observați că fișierul test_mmap (creat de programul mmap cu MAP_SHARED) conține 100000 de linii:

cat test_mmap | wc -l

În programul mmap.c schimbați flagul de creare al memoriei partajate din MAP_SHARED în MAP_PRIVATE, compilați și rulați din nou:

./mmap
cat test_mmap | wc -l

Intrați în directorul 3-efence și urmăriți sursa bug.c. Compilați și rulați executabilul bug:

make
./bug

Folosiți ElectricFence pentru a prinde situația de 'buffer underrun' urmărind pașii:

• Instalați pachetul electric-fence în cazul in care biblioteca libefence.so nu se găsește pe sistem.
• Setați în bash variabila de mediu EF_PROTECT_BELOW la 1:

  export EF_PROTECT_BELOW=1

• Creați și rulați programul ef_bug utilizând makefile-ul Makefile_efence:

  make -f Makefile_efence
  ./ef_bug

$ wget http://ro.archive.ubuntu.com/ubuntu/pool/main/e/electric-fence/electric-fence_2.2.4_i386.deb
$ sudo dpkg -i electric-fence_2.2.4_i386.deb

Intrați în directorul 4-cp și completați sursa mycp.c astfel încât să realizeze copierea unui fișier primit ca argument. Pentru aceasta, mapați ambele fișiere în memorie și realizați copierea folosind memcpy. Urmăriți comentariile cu TODO din sursă și următoarele hint-uri:

• Înainte de mapare, aflați dimensiunea fișierului sursă folosind fstat.
• Trunchiați fișierul destinație la dimensiunea fișierului sursă folosing ftruncate.
• Folosiți MAP_SHARED pentru mapare pentru a fi transmise schimbările în fișier: rețineți faptul că apelul mmap folosește una dintre opțiunile MAP_SHARED sau MAP_PRIVATE (una singură)
• Pentru fișierul de intrare protecția trebuie să fie PROT_READ: fișierul a fost deschis read-only.
• Pentru fișierul de ieșire protecția trebuie să fie PROT_READ | PROT_WRITE; anumite arhitecturi/implementări se pot plânge dacă folosiți doar PROT_WRITE.
• Argumentele funcției memcpy sunt, în ordine: destinația, sursa, numărul de octeți care să fie copiați.
• Revedeți secțiunea maparea fișierelor.
• Asigurați persistența datelor pe sistemul de fișiere printr-un apel explicit msync

Puteți testa în felul următor:

./mycp Makefile /tmp/Makefile
diff Makefile /tmp/Makefile

Verificați cum realizează utilitarul cp copierea de fișiere (folosind mmap sau read/write) folosind strace.

Intrați în directorul 5-prot și inspectați sursa prot.c.

Creați o zonă de memorie în spațiul de adresă, formată din trei pagini virtuale (folosiți un singur apel mmap). Prima pagină nu va avea vreun drept, a doua va avea drepturi de citire, iar a treia va avea drepturi de scriere (folosiți mprotect pentru a configura drepturile fiecărei pagini). Testați comportamentul programului când se fac accese de citire și scriere în aceste zone. Completați comentariile cu TODO 1.

Adăugați un handler de tratare a excepțiilor care să remapeze incremental zonele cu protecție de citire și scriere la generarea excepțiilor. Astfel, dacă pagina nu are vreun drept, la page fault se va remapa cu drepturi de citire. Dacă pagina are drepturi de citire, la page fault se va remapa cu drepturi de citire + drepturi de scriere. Completați comentariile cu TODO 2.

Intrați în directorul 6-faults și urmăriți conținutul fișierului fork-faults.c.

Vom folosi utilitarul pidstat ( tutorial pidstat) din pachetul sysstat pentru a monitoriza page fault-urile făcute de un proces.

student@spook:~$ wget http://ro.archive.ubuntu.com/ubuntu/pool/main/s/sysstat/sysstat_11.2.0-1_i386.deb
student@spook:~$ sudo dpkg -i sysstat_11.2.0-1_i386.deb 

Rulați programul fork-faults. Într-o altă consolă executați comanda

pidstat -r -T ALL -p $(pidof fork-faults) 5

pentru a urmări page fault-urile. Comanda de mai sus vă afișează câte un mesaj la fiecare 5 secunde; ne interesează valorile minflt-nr.

Pe rând, apăsați tasta ENTER în consola unde ați rulat programul fork-faults și observați output-ul comenzii pidstat. Urmăriți evoluția numărului de page fault-uri pentru cele două procese: părinte și copil. Page fault-urile care apar în cazul unui copy-on-write în procesul copil vor fi vizibile ulterior și în procesul părinte (după ce procesul copil își încheie execuția).

Vă aflați într-o situație în care trebuie să procesați în timp real datele dintr-un buffer și vreți să evitați swaparea paginilor. Intrați în directorul 7-paging și completați TODO-urile astfel încât paginarea va fi blocată pentru variabila data pe parcursul lucrului cu aceasta, iar la final va fi deblocată. Deși pe Linux adresa va fi aliniată automat la dimensiunea unei pagini, acest lucru nu se întâmplă pe toate sistemele POSIX compliant, prin urmare este o practică bună să o aliniem manual.

Deoarece variabila data este o variabilă locală a funcției main, aceasta va fi alocată pe stivă. Rulați programul paging și folosiți, într-o altă consolă, comanda

pmap -X -p $(pidof paging)

după fiecare apăsare a tastei ENTER. Veți observa blocarea/deblocarea paginării pentru paginile mapate pe stivă ce conțin cel puțin un byte al variabilei data.

Intrați în directorul 8-hack. Programul apelează funcția foo(). Având determinată pagina în care se află funcția în spațiul de adresă al procesului, i se schimbă drepturile de acces în PROT_READ|PROT_WRITE|PROT_EXEC și se modifică valoarea de retur a funcției (se scrie în segmentul de cod).

Analizați cu atenție programul. Analizați comportamentul cu gdb. Având pid-ul procesului afișat la stdout, folosiți pmap pentru a observa pagina cu drepturile schimbate. Observați tipul de acces pentru celelalte pagini din spațiul de adresă al procesului.

Modificați drepturile de acces în PROT_READ|PROT_EXEC, compilați și rulați din nou. Observați că fără drepturi de scriere execuția programului este încheiată de un semnal SIGSEGV.

• Wikipedia: Memory Management
• Memory Management in Linux
• Opengroup - mmap