[so] [Memorie Virutuala][Ce determina Segmentation fault]

Costin Lupu costin.lup at gmail.com
Fri Apr 8 12:25:06 EEST 2016


Salutare, Tiberiu,

On Thu, 2016-04-07 at 17:46 +0000, Tiberiu IORGULESCU (25243) via so
wrote:
> Am o intrebare:
> Cum se prinde sistemul de operare daca sa dea sau nu sigsegv (sau ce
> se intampla de fapt in spate atunci cand se aloca o pagina?).
> 
> De exemplu, daca eu aloc o zona de memorie, ea nu se afla nici in
> memoria fizica (datorita "demand paging"), nici in memoria secundara,
> deci in tabela de pagini presupun ca flag-ul de validitate ar trebui
> sa fie invalid. Si atunci de unde stie daca a fost alocata de mine?
> Sau care e diferenta intre asta si cazul in care pur si simplu incerc
> sa scriu la o adresa oarecare din spatiul meu virtual, fara sa fi
> alocat nimic acolo?

Secretul care îți răspunde la întrebarea ta vine de la faptul că pe
Linux apelul de sistem 'mmap' nu creează pe loc, imediat, maparea între
pagina virtuală și pagina fizică, ci doar creează o intrare/informație
în gestiunea internă kernelului pentru memoria virtuală asociată
procesului care apelează 'mmap'. Astfel, primul acces ulterior la acea
pagină va avea același efect ca în cazul accesului la o pagină care nu
îi aparține procesului pentru că nu există încă maparea în tabelul de
pagini.

Puțin background: De fiecare dată când un proces accesează memorie care
nu îi aparține (a se citi "pentru care nu are o intrare în tabela de
pagini"), __hardware-ul__ va semnala eroarea generând o întrerupere
(cunoscută ca 'trap') care va fi tratată de kernel. Deci, și în cazul în
care accesul s-a făcut pentru o pagină alocată cu 'mmap' (vorbim de
primul acces la o astfel de pagină), hardware-ul va genera trap-ul.

Trap-ul, repet, este tratat de kernel. Acum, kernel-ul trebuie să
decidă:
a) Este cumva o pagină alocată cu 'mmap', dar accesată prima dată?
Atunci creează maparea efectivă (noua intrare în tabela de pagini a
procesului) și îi dă controlul înapoi procesului. Asta se mai cheamă
"minor page fault" (vezi laboratorul 6 [1]).
b) Este o pagină care nu îi aparține procesului? Atunci îi va trimite
acestuia SIGSEGV. 

Am simplificat mult aici arborele de decizie al kernelului în cazul unui
page-fault. Mai multe informații găsești în "Understanding the Linux
Kernel", ediția 3, [2], o carte care intră în bibliografia cursului
Sisteme de Operare 2, anul IV. Ai acolo:
- secțiunea '16.2.2. Creating a Memory Mapping', p791, îți descrie în
detaliu ce face 'mmap'; secțiunea '16.2.4. Demand Paging for Memory
Mapping', p793, subliniază faptul că maparea nu se face în momentul
apelului 'mmap', ci ulterior
- secțiunea '9.4. Page Fault Exception Handler', p457, prezintă în
detaliu arborele de decizie și pașii urmați de kernel în tratarea unui
'page fault'

Observații:
Asta este politica Linux-ului. Ar fi putut crea la apelul 'mmap'
mapările necesare și astfel nu s-ar fi mai generat page fault-uri la
primele accesări ale paginilor alocate. Însă abordarea Linux-ului are
avantajul că păstrează memoria cât mai puțin ocupată: va aloca pagini
'on demand', doar atunci când procesul o va cere prin accesare
(citire/scriere/execuție). Dezavantajul evident este tot acest overhead,
deciziile pe care trebuie să le ia kernel-ul și parcurgerea aceluiași
arbore de decizie ca în cazul unui acces invalid normal. Se consideră
totuși că page fault-urile sunt evenimente rare și în consecință nu
costă foarte mult sistemul.

[1] 
http://ocw.cs.pub.ro/courses/so/laboratoare/laborator-06#exercitiul_6_-_page_fault-uri_05p
[2] https://elf.cs.pub.ro/so2/res/doc/lin-kernel/O%27Reilly%20-%
20Understanding%20The%20Linux%20Kernel%20-%203rd%20Edition.pdf

Costin




More information about the so mailing list