\begin{figure}[htb]
\centering
- \includegraphics[width=14cm]{img/proc_beginend}
+ \includegraphics[width=9cm]{img/proc_beginend}
\caption{Schema dell'avvio e della conclusione di un programma.}
\label{fig:proc_prog_start_stop}
\end{figure}
Si ricordi infine che un programma può anche essere interrotto dall'esterno
attraverso l'uso di un segnale (modalità di conclusione non mostrata in
-fig.~\ref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
-cap.~\ref{cha:signals}.
+fig.~\ref{fig:proc_prog_start_stop}); tratteremo nei dettagli i segnali e la
+loro gestione nel capitolo \ref{cha:signals}.
\subsection{I concetti generali}
\label{sec:proc_mem_gen}
-Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli
-di basso livello dipendono spesso in maniera diretta dall'architettura
-dell'hardware), ma quello più tipico, usato dai sistemi unix-like come Linux è
-la cosiddetta \textsl{memoria virtuale}\index{memoria~virtuale} che consiste
-nell'assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare,
-in cui gli indirizzi vanno da zero ad un qualche valore massimo.\footnote{nel
- caso di Linux fino al kernel 2.2 detto massimo era, per macchine a 32bit, di
- 2Gb. Con il kernel 2.4 ed il supporto per la \textit{high-memory} il limite
- è stato esteso anche per macchine a 32 bit.}
+Ci sono vari modi in cui i sistemi operativi organizzano la memoria, ed i
+dettagli di basso livello dipendono spesso in maniera diretta
+dall'architettura dell'hardware, ma quello più tipico, usato dai sistemi
+unix-like come Linux è la cosiddetta \textsl{memoria
+ virtuale}\index{memoria~virtuale} che consiste nell'assegnare ad ogni
+processo uno spazio virtuale di indirizzamento lineare, in cui gli indirizzi
+vanno da zero ad un qualche valore massimo.\footnote{nel caso di Linux fino al
+ kernel 2.2 detto massimo era, per macchine a 32bit, di 2Gb. Con il kernel
+ 2.4 ed il supporto per la \textit{high-memory} il limite è stato esteso
+ anche per macchine a 32 bit.}
Come accennato in cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del
indirizzi possibili sono utilizzabili, e quelli usabili non sono
necessariamente adiacenti).
-Per la gestione da parte del kernel la memoria virtuale viene divisa in pagine
-di dimensione fissa (che ad esempio sono di 4kb su macchine a 32 bit e 8kb
-sulle alpha, valori strettamente connessi all'hardware di gestione della
-memoria),\footnote{con le versioni più recenti del kernel è possibile anche
- utilizzare pagine di dimensioni maggiori, per sistemi con grandi
- quantitativi di memoria in cui l'uso di pagine troppo piccole comporta una
- perdita di prestazioni.} e ciascuna pagina della memoria virtuale è
-associata ad un supporto che può essere una pagina di memoria reale o ad un
-dispositivo di stoccaggio secondario (in genere lo spazio disco riservato alla
-swap, o i file che contengono il codice).
-
-Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
-diverse pagine di memoria virtuale appartenenti a processi diversi (come
-accade in genere per le pagine che contengono il codice delle librerie
-condivise). Ad esempio il codice della funzione \func{printf} starà su una
-sola pagina di memoria reale che farà da supporto a tutte le pagine di memoria
-virtuale di tutti i processi che hanno detta funzione nel loro codice.
-
-La corrispondenza fra le pagine della \index{memoria~virtuale}memoria virtuale
-e quelle della memoria fisica della macchina viene gestita in maniera
-trasparente dall'hardware di gestione della memoria (la \textit{Memory
- Management Unit} del processore). Poiché in genere la memoria fisica è solo
-una piccola frazione della memoria virtuale, è necessario un meccanismo che
-permetta di trasferire le pagine che servono dal supporto su cui si trovano in
-memoria, eliminando quelle che non servono. Questo meccanismo è detto
-\textsl{paginazione}\index{paginazione} (o \textit{paging}), ed è uno dei
-compiti principali del kernel.
+Per la gestione da parte del kernel la memoria viene divisa in pagine di
+dimensione fissa,\footnote{inizialmente questi erano di 4kb sulle macchine a
+ 32 bit e di 8kb sulle alpha, con le versioni più recenti del kernel è
+ possibile anche utilizzare pagine di dimensioni maggiori (4Mb), per sistemi
+ con grandi quantitativi di memoria in cui l'uso di pagine troppo piccole
+ comporta una perdita di prestazioni.} e ciascuna pagina nello spazio di
+indirizzi virtuale è associata ad un supporto che può essere una pagina di
+memoria reale o ad un dispositivo di stoccaggio secondario (come lo spazio
+disco riservato alla swap, o i file che contengono il codice). Per ciasun
+processo il kernel si cura di mantenere un mappa di queste corrispondenze
+nella cosiddetta \itindex{page~table}\textit{page table}.\footnote{questa è
+ una semplificazione brutale, il meccanismo è molto più complesso; una buona
+ trattazione di come Linux gestisce la memoria virtuale si trova su
+ \cite{LinVM}.}
+
+Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
+memoria virtuale appartenenti a processi diversi (come accade in genere per le
+pagine che contengono il codice delle librerie condivise). Ad esempio il
+codice della funzione \func{printf} starà su una sola pagina di memoria reale
+che farà da supporto a tutte le pagine di memoria virtuale di tutti i processi
+che hanno detta funzione nel loro codice.
+
+La corrispondenza fra le pagine della \index{memoria~virtuale} memoria
+virtuale di un processo e quelle della memoria fisica della macchina viene
+gestita in maniera trasparente dal kernel.\footnote{in genere con l'ausilio
+ dell'hardware di gestione della memoria (la \textit{Memory Management Unit}
+ del processore), con i kernel della serie 2.6 è comunque diventato possibile
+ utilizzare Linux anche su architetture che non dispongono di una MMU.}
+Poiché in genere la memoria fisica è solo una piccola frazione della memoria
+virtuale, è necessario un meccanismo che permetta di trasferire le pagine che
+servono dal supporto su cui si trovano in memoria, eliminando quelle che non
+servono. Questo meccanismo è detto \textsl{paginazione} \index{paginazione}
+(o \textit{paging}), ed è uno dei compiti principali del kernel.
Quando un processo cerca di accedere ad una pagina che non è nella memoria
-reale, avviene quello che viene chiamato un \textit{page
- fault}\itindex{page~fault}; l'hardware di gestione della memoria genera
-un'interruzione e passa il controllo al kernel il quale sospende il processo e
-si incarica di mettere in RAM la pagina richiesta (effettuando tutte le
-operazioni necessarie per reperire lo spazio necessario), per poi restituire
-il controllo al processo.
+reale, avviene quello che viene chiamato un \itindex{page~fault} \textit{page
+ fault}; la gestione della memoria genera un'interruzione e passa il
+controllo al kernel il quale sospende il processo e si incarica di mettere in
+RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
+reperire lo spazio necessario), per poi restituire il controllo al processo.
Dal punto di vista di un processo questo meccanismo è completamente
trasparente, e tutto avviene come se tutte le pagine fossero sempre
in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
esigenze specifiche di prestazioni è possibile usare delle funzioni che
permettono di bloccare il meccanismo della paginazione\index{paginazione} e
-mantenere fisse delle pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
+mantenere fisse delle pagine in memoria (vedi
+sez.~\ref{sec:proc_mem_lock}). Inoltre per certe applicazioni gli algoritmi di
+gestione della memoria
\subsection{La struttura della memoria di un processo}
commette quando si è manipolato male un puntatore e genera quello che viene
chiamato un \textit{segmentation fault}. Se si tenta cioè di leggere o
scrivere da un indirizzo per il quale non esiste un'associazione della pagina
-virtuale, il kernel risponde al relativo \textit{page
- fault}\itindex{page~fault} mandando un segnale \const{SIGSEGV} al processo,
-che normalmente ne causa la terminazione immediata.
+virtuale, il kernel risponde al relativo \itindex{page~fault} \textit{page
+ fault} mandando un segnale \const{SIGSEGV} al processo, che normalmente ne
+causa la terminazione immediata.
È pertanto importante capire come viene strutturata \textsl{la memoria
- virtuale}\index{memoria~virtuale} di un processo. Essa viene divisa in
+ virtuale} \index{memoria~virtuale} di un processo. Essa viene divisa in
\textsl{segmenti}, cioè un insieme contiguo di indirizzi virtuali ai quali il
processo può accedere. Solitamente un programma C viene suddiviso nei
seguenti segmenti:
\subsection{Allocazione della memoria per i programmi C}
\label{sec:proc_mem_alloc}
-Il C supporta, a livello di linguaggio, soltanto due modalità di allocazione
-della memoria: l'\textsl{allocazione statica} e l'\textsl{allocazione
- automatica}.
+Il C supporta direttamente, come linguaggio di programmazione, soltanto due
+modalità di allocazione della memoria: l'\textsl{allocazione statica} e
+l'\textsl{allocazione automatica}.
L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
globali e le variabili statiche, cioè le variabili il cui valore deve essere
cioè definire in fase di programmazione una variabile le cui dimensioni
possano essere modificate durante l'esecuzione del programma. Per questo le
librerie del C forniscono una serie opportuna di funzioni per eseguire
-l'allocazione dinamica di memoria (in genere nello heap). Le variabili il
-cui contenuto è allocato in questo modo non potranno essere usate direttamente
-come le altre, ma l'accesso sarà possibile solo in maniera indiretta,
-attraverso dei puntatori.
+l'allocazione dinamica di memoria (in genere nello heap).
+
+Le variabili il cui contenuto è allocato in questo modo non potranno essere
+usate direttamente come le altre, ma l'accesso sarà possibile solo in maniera
+indiretta, attraverso i puntatori alla memoria loro riservata che si sono
+ottenuti dalle funzioni di allocazione.
\subsection{Le funzioni \func{malloc}, \func{calloc}, \func{realloc} e
% \subsection{La personalizzazione delle funzioni di allocazione}
% \label{sec:proc_mem_malloc_custom}
+% TODO documentare \func{madvise}
+% TODO documentare \func{mincore}
+% TODO documentare \func{mprotect} forse da mettere insieme a mmap
\subsection{Il controllo della memoria virtuale}
\label{sec:proc_mem_lock}
crittografia richiedono il blocco di alcune pagine di memoria.
\end{itemize}
-\itindbeg{memory~locking}
+\itindbeg{memory~locking}
+
Il meccanismo che previene la paginazione\index{paginazione} di parte della
memoria virtuale di un processo è chiamato \textit{memory locking} (o
\textsl{blocco della memoria}). Il blocco è sempre associato alle pagine della
memoria virtuale del processo, e non al segmento reale di RAM su cui essa
-viene mantenuta.
-
-La regola è che se un segmento di RAM fa da supporto ad almeno una pagina
-bloccata allora esso viene escluso dal meccanismo della
+viene mantenuta. La regola è che se un segmento di RAM fa da supporto ad
+almeno una pagina bloccata allora esso viene escluso dal meccanismo della
paginazione\index{paginazione}. I blocchi non si accumulano, se si blocca due
volte la stessa pagina non è necessario sbloccarla due volte, una pagina o è
-bloccata oppure no.
+bloccata oppure no.
Il \textit{memory lock} persiste fintanto che il processo che detiene la
memoria bloccata non la sblocca. Chiaramente la terminazione del processo
comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
tutti i suoi \textit{memory lock}. Infine i \textit{memory lock} non sono
-ereditati dai processi figli.\footnote{ma siccome Linux usa il
+ereditati dai processi figli,\footnote{ma siccome Linux usa il
\itindex{copy~on~write}\textit{copy on write} (vedi
sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio sono mantenuti
sullo stesso segmento di RAM del padre, quindi fintanto che un figlio non
- scrive su un segmento, può usufruire del \textit{memory lock} del padre.}
+ scrive su un segmento, può usufruire del \textit{memory lock} del padre.} e
+vengono automaticamente rimossi se si pone in esecuzione un altro programma
+con \func{exec} (vedi sez.~\ref{sec:proc_exec}).
Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
la memoria fisica disponibile nel sistema, questo ha un evidente impatto su
-tutti gli altri processi, per cui solo un processo con i privilegi di
-amministratore (vedremo in sez.~\ref{sec:proc_perms} cosa significa) ha la
-capacità di bloccare una pagina. Ogni processo può però sbloccare le pagine
-relative alla propria memoria.
+tutti gli altri processi, per cui fino al kernel 2.6.9 solo un processo con i
+privilegi opportuni (la \itindex{capability}\textit{capability}
+\const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la
+capacità di bloccare una pagina.
Il sistema pone dei limiti all'ammontare di memoria di un processo che può
essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
standard POSIX.1 richiede che sia definita in \file{unistd.h} la macro
\macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
-\textit{memory locking} e la costante \const{PAGESIZE} in \file{limits.h} per
-indicare la dimensione di una pagina in byte.
+\textit{memory locking}. Inoltre in alcuni sistemi è definita la costante
+\const{PAGE\_SIZE} in \file{limits.h} per indicare la dimensione di una pagina
+in byte.\footnote{con Linux questo non avviene e si deve ricorrere alla
+ funzione \func{getpagesize}, vedi sez.~\ref{sec:sys_memory_res}.}
+
+
+Con il kernel 2.6.9 anche un processo normale può bloccare la propria
+memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
+ dare privilegi eccessivi a programmi di crittografia, che necessitano di
+ questa funzionalità, ma che devono essere usati da utenti normali.} ma
+mentre un processo privilegiato non ha limiti sulla quantità di memoria che
+può bloccare, un processo normale è soggetto al limite della risorsa
+\const{RLIMIT\_MEMLOCK} (vedi sez.~\ref{sec:sys_resource_limit}). In generale
+poi ogni processo può sbloccare le pagine relative alla propria memoria, se
+però diversi processi bloccano la stessa pagina questa resterà bloccata
+fintanto che ci sarà almeno un processo che la blocca.
Le funzioni per bloccare e sbloccare la paginazione\index{paginazione} di
singole sezioni di memoria sono \funcd{mlock} e \funcd{munlock}; i loro
corrispondono allo spazio di indirizzi del processo o si è ecceduto
il numero massimo consentito di pagine bloccate.
\item[\errcode{EINVAL}] \param{len} non è un valore positivo.
+ \item[\errcode{EPERM}] con un kernel successivo al 2.6.9 il processo non è
+ privilegiato e si un limite nullo per \const{RLIMIT\_MEMLOCK}.
\end{errlist}
e, per \func{mlock}, anche \errval{EPERM} quando il processo non ha i
privilegi richiesti per l'operazione.}
paginazione\index{paginazione} per l'intervallo di memoria specificato dagli
argomenti, che ne indicano nell'ordine l'indirizzo iniziale e la lunghezza.
Tutte le pagine che contengono una parte dell'intervallo bloccato sono
-mantenute in RAM per tutta la durata del blocco.
+mantenute in RAM per tutta la durata del blocco.\footnote{con altri kernel si
+ può ottenere un errore di \errcode{EINVAL} se \param{addr} non è un multiplo
+ della dimensione delle pagine di memoria.}
Altre due funzioni, \funcd{mlockall} e \funcd{munlockall}, consentono di
bloccare genericamente la paginazione\index{paginazione} per l'intero spazio
\funcdecl{int munlockall(void)}
Sblocca la paginazione per lo spazio di indirizzi del processo corrente.
- \bodydesc{Codici di ritorno ed errori sono gli stessi di \func{mlock}
- e \func{munlock}.}
+ \bodydesc{Codici di ritorno ed errori sono gli stessi di \func{mlock} e
+ \func{munlock}, con un kernel successivo al 2.6.9 l'uso di
+ func{munlockall} senza la la \itindex{capability}\textit{capability}
+\const{CAP\_IPC\_LOCK} genera un errore di \errcode{EPERM}.}
\end{functions}
L'argomento \param{flags} di \func{mlockall} permette di controllarne il
projects / gapil.git / blobdiff