3 %% Copyright (C) 2000-2018 by Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
12 \chapter{La gestione dei processi}
13 \label{cha:process_handling}
15 Come accennato nell'introduzione in un sistema unix-like tutte le operazioni
16 vengono svolte tramite opportuni processi. In sostanza questi ultimi vengono
17 a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
19 Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come
20 unità a se stante, in questo esamineremo il funzionamento dei processi
21 all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
22 della terminazione dei processi, della gestione dei loro attributi e
23 privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
24 finale introdurremo alcune problematiche generiche della programmazione in
25 ambiente multitasking.
28 \section{Le funzioni di base della gestione dei processi}
29 \label{sec:proc_handling}
31 In questa sezione tratteremo le problematiche della gestione dei processi
32 all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con una
33 panoramica dell'architettura dei processi, tratteremo poi le funzioni
34 elementari che permettono di leggerne gli identificatori, per poi passare alla
35 spiegazione delle funzioni base che si usano per la creazione e la
36 terminazione dei processi, e per la messa in esecuzione degli altri programmi.
39 \subsection{L'architettura della gestione dei processi}
40 \label{sec:proc_hierarchy}
42 A differenza di quanto avviene in altri sistemi, ad esempio nel VMS, dove la
43 generazione di nuovi processi è un'operazione privilegiata, una delle
44 caratteristiche fondanti di Unix, che esamineremo in dettaglio più avanti, è
45 che qualunque processo può a sua volta generarne altri. Ogni processo è
46 identificato presso il sistema da un numero univoco, il cosiddetto
47 \textit{Process ID}, o più brevemente \ids{PID}, assegnato in forma
48 progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato.
50 Una seconda caratteristica di un sistema unix-like è che la generazione di un
51 processo è un'operazione separata rispetto al lancio di un programma. In
52 genere la sequenza è sempre quella di creare un nuovo processo, il quale
53 eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
54 quello che fa la shell quando mette in esecuzione il programma che gli
55 indichiamo nella linea di comando.
57 Una terza caratteristica del sistema è che ogni processo è sempre stato
58 generato da un altro processo, il processo generato viene chiamato
59 \textit{processo figlio} (\textit{child process}) mentre quello che lo ha
60 generato viene chiamato \textsl{processo padre} (\textit{parent
61 process}). Questo vale per tutti i processi, con una sola eccezione; dato
62 che ci deve essere un punto di partenza esiste un processo iniziale (che
63 normalmente è \cmd{/sbin/init}), che come accennato in
64 sez.~\ref{sec:intro_kern_and_sys} viene lanciato dal kernel alla conclusione
65 della fase di avvio. Essendo questo il primo processo lanciato dal sistema ha
66 sempre \ids{PID} uguale a 1 e non è figlio di nessun altro processo.
68 Ovviamente \cmd{init} è un processo particolare che in genere si occupa di
69 lanciare tutti gli altri processi necessari al funzionamento del sistema,
70 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
71 amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
72 essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
73 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
74 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
75 \cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
76 posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come
77 parametro di avvio del kernel, l'argomento è di natura sistemistica e
78 trattato in sez.~5.3 di \cite{AGL}.}
83 [piccardi@gont piccardi]$ \textbf{pstree -n}
100 |-bash---startx---xinit-+-XFree86
101 | `-WindowMaker-+-ssh-agent
109 | |-wterm---bash---pstree
110 | `-wterm---bash-+-emacs
117 \caption{L'albero dei processi, così come riportato dal comando
119 \label{fig:proc_tree}
122 Dato che tutti i processi attivi nel sistema sono comunque generati da
123 \cmd{init} o da uno dei suoi figli si possono classificare i processi con la
124 relazione padre/figlio in un'organizzazione gerarchica ad albero. In
125 fig.~\ref{fig:proc_tree} si è mostrato il risultato del comando \cmd{pstree}
126 che permette di visualizzare questa struttura, alla cui base c'è \cmd{init}
127 che è progenitore di tutti gli altri processi.\footnote{in realtà questo non è
128 del tutto vero, in Linux, specialmente nelle versioni più recenti del
129 kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd},
130 ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con
131 \ids{PID} successivi ad uno, sono in realtà processi interni al kernel e che
132 non rientrano in questa classificazione.}
134 \itindbeg{process~table}
136 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
137 \textit{process table}. Per ciascun processo viene mantenuta una voce in
138 questa tabella, costituita da una struttura \kstruct{task\_struct}, che
139 contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
140 usate a questo scopo sono dichiarate nell'\textit{header file}
141 \file{linux/sched.h}, ed in fig.~\ref{fig:proc_task_struct} si è riportato uno
142 schema semplificato che mostra la struttura delle principali informazioni
143 contenute nella \texttt{task\_struct}, che in seguito incontreremo a più
147 \centering \includegraphics[width=14cm]{img/task_struct}
148 \caption{Schema semplificato dell'architettura delle strutture (
149 \kstructd{task\_struct}, \kstructd{fs\_struct}, \kstructd{file\_struct})
150 usate dal kernel nella gestione dei processi.}
151 \label{fig:proc_task_struct}
154 \itindend{process~table}
156 % TODO la task_struct è cambiata per qualche dettaglio vedi anche
157 % http://www.ibm.com/developerworks/linux/library/l-linux-process-management/
158 % TODO completare la parte su quando viene chiamato lo scheduler.
162 Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \textit{scheduler} che
163 decide quale processo mettere in esecuzione; esso viene eseguito in occasione
164 di dell'invocazione di ogni \textit{system call} ed per ogni interrupt
165 dall'hardware oltre che in una serie di altre occasioni, e può essere anche
166 attivato esplicitamente. Il timer di sistema provvede comunque a che esso sia
167 invocato periodicamente, generando un interrupt periodico secondo una
168 frequenza predeterminata, specificata dalla costante \const{HZ} del kernel
169 (torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura
170 che lo \textit{scheduler} venga comunque eseguito ad intervalli regolari e
171 possa prendere le sue decisioni.
173 A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
174 completamente diverso, detto \textit{tickless}, in cui non c'è più una
175 interruzione periodica con frequenza prefissata, ma ad ogni chiamata del timer
176 viene programmata l'interruzione successiva sulla base di una stima; in questo
177 modo si evita di dover eseguire un migliaio di interruzioni al secondo anche
178 su macchine che non stanno facendo nulla, con un forte risparmio nell'uso
179 dell'energia da parte del processore che può essere messo in stato di
180 sospensione anche per lunghi periodi di tempo.
182 Ma, indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
183 viene eseguito lo \textit{scheduler} effettua il calcolo delle priorità dei
184 vari processi attivi (torneremo su questo in sez.~\ref{sec:proc_priority}) e
185 stabilisce quale di essi debba essere posto in esecuzione fino alla successiva
190 \subsection{Gli identificatori dei processi}
193 \itindbeg{Process~ID~(PID)}
195 Come accennato nella sezione precedente ogni processo viene identificato dal
196 sistema da un numero identificativo univoco, il \textit{process ID} o
197 \ids{PID}. Questo è un tipo di dato standard, \type{pid\_t}, che in genere è un
198 intero con segno (nel caso di Linux e della \acr{glibc} il tipo usato è
201 Il \ids{PID} viene assegnato in forma progressiva ogni volta che un nuovo
202 processo viene creato,\footnote{in genere viene assegnato il numero successivo
203 a quello usato per l'ultimo processo creato, a meno che questo numero non
204 sia già utilizzato per un altro \ids{PID}, \acr{pgid} o \acr{sid} (vedi
205 sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il
206 tradizionalmente il \ids{PID} un numero positivo memorizzato in un intero a 16
207 bit, arriva ad un massimo di 32768. Oltre questo valore l'assegnazione
208 riparte dal numero più basso disponibile a partire da un minimo di
209 300,\footnote{questi valori, fino al kernel 2.4.x, erano definiti dalla macro
210 \constd{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del
211 kernel, con il 2.6.x e la nuova interfaccia per i \textit{thread} anche il
212 meccanismo di allocazione dei \ids{PID} è stato modificato ed il valore
213 massimo è impostabile attraverso il file \sysctlfiled{kernel/pid\_max} e di
214 default vale 32768.} che serve a riservare i \ids{PID} più bassi ai processi
215 eseguiti direttamente dal kernel. Per questo motivo, come visto in
216 sez.~\ref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
217 \ids{PID} uguale a uno.
219 \itindbeg{Parent~Process~ID~(PPID)}
221 Tutti i processi inoltre memorizzano anche il \ids{PID} del genitore da cui
222 sono stati creati, questo viene chiamato in genere \ids{PPID} (da
223 \textit{Parent Process ID}). Questi due identificativi possono essere
224 ottenuti usando le due funzioni di sistema \funcd{getpid} e \funcd{getppid}, i
230 \fdecl{pid\_t getpid(void)}
231 \fdesc{Restituisce il \ids{PID} del processo corrente..}
232 \fdecl{pid\_t getppid(void)}
233 \fdesc{Restituisce il \ids{PID} del padre del processo corrente.}
235 {Entrambe le funzioni non riportano condizioni di errore.}
238 \noindent esempi dell'uso di queste funzioni sono riportati in
239 fig.~\ref{fig:proc_fork_code}, nel programma \file{fork\_test.c}.
241 Il fatto che il \ids{PID} sia un numero univoco per il sistema lo rende un
242 candidato per generare ulteriori indicatori associati al processo di cui
243 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
244 funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
245 \ids{PID} per generare un \textit{pathname} univoco, che non potrà essere
246 replicato da un altro processo che usi la stessa funzione. Questo utilizzo
247 però può risultare pericoloso, un \ids{PID} infatti è univoco solo fintanto
248 che un processo è attivo, una volta terminato esso potrà essere riutilizzato
249 da un processo completamente diverso, e di questo bisogna essere ben
252 Tutti i processi figli dello stesso processo padre sono detti
253 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
254 sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
255 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
256 cap.~\ref{cha:session}, dove esamineremo gli altri identificativi associati ad
257 un processo e le varie relazioni fra processi utilizzate per definire una
260 Oltre al \ids{PID} e al \ids{PPID}, e a quelli che vedremo in
261 sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni
262 processo vengono associati degli ulteriori identificatori ed in particolare
263 quelli che vengono usati per il controllo di accesso. Questi servono per
264 determinare se un processo può eseguire o meno le operazioni richieste, a
265 seconda dei privilegi e dell'identità di chi lo ha posto in esecuzione;
266 l'argomento è complesso e sarà affrontato in dettaglio in
267 sez.~\ref{sec:proc_perms}.
269 \itindend{Process~ID~(PID)}
270 \itindend{Parent~Process~ID~(PPID)}
272 \subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
273 \label{sec:proc_fork}
275 La funzione di sistema \func{fork} è la funzione fondamentale della gestione
276 dei processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
277 processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
278 \textit{system call} usata da Linux per creare nuovi processi è \func{clone}
279 (vedi \ref{sec:process_clone}), anche perché a partire dalla \acr{glibc}
280 2.3.3 non viene più usata la \textit{system call} originale, ma la stessa
281 \func{fork} viene implementata tramite \func{clone}, cosa che consente una
282 migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
283 centrale tutte le volte che si devono scrivere programmi che usano il
284 multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
285 \textit{thread}\unavref{ che tratteremo al cap.~\ref{cha:threads}}, è in
286 parte minore, ma \func{fork} resta comunque la funzione principale per la
287 creazione di processi.} Il prototipo di \funcd{fork} è:
291 \fdecl{pid\_t fork(void)}
292 \fdesc{Crea un nuovo processo.}
295 {La funzione ritorna in caso di successo il \ids{PID} del figlio nel padre e
296 $0$ nel figlio mentre ritorna $-1$ nel padre, senza creare il figlio, per un
297 errore, al caso \var{errno} assumerà uno dei valori:
299 \item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
300 processo (per allocare la tabella delle pagine e le strutture del task) o
301 si è esaurito il numero di processi disponibili.
302 \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
303 strutture necessarie al kernel per creare il nuovo processo.
307 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
308 il processo figlio continuano ad essere eseguiti normalmente, a partire
309 dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia
310 del padre, e riceve una copia dei segmenti di testo, dati e dello
311 \textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo
312 stesso codice del padre. Si tenga presente però che la memoria è copiata e non
313 condivisa, pertanto padre e figlio vedranno variabili diverse e le eventuali
314 modifiche saranno totalmente indipendenti.
316 \itindbeg{copy~on~write}
318 Per quanto riguarda la gestione della memoria, in generale il segmento di
319 testo, che è identico per i due processi, è condiviso e tenuto in sola lettura
320 per il padre e per i figli. Per gli altri segmenti Linux utilizza la tecnica
321 del \textit{copy on write}. Questa tecnica comporta che una pagina di memoria
322 viene effettivamente copiata per il nuovo processo solo quando ci viene
323 effettuata sopra una scrittura, e si ha quindi una reale differenza fra padre
324 e figlio. In questo modo si rende molto più efficiente il meccanismo della
325 creazione di un nuovo processo, non essendo più necessaria la copia di tutto
326 lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di memoria
327 che sono state modificate, e solo al momento della modifica stessa.
329 \itindend{copy~on~write}
331 La differenza che si ha nei due processi è che nel processo padre il valore di
332 ritorno della funzione \func{fork} è il \ids{PID} del processo figlio, mentre
333 nel figlio è zero; in questo modo il programma può identificare se viene
334 eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
335 due volte, una nel padre e una nel figlio.
337 La scelta di questi valori di ritorno non è casuale, un processo infatti può
338 avere più figli, ed il valore di ritorno di \func{fork} è l'unico che gli
339 permette di identificare qual è quello appena creato. Al contrario un figlio
340 ha sempre un solo padre il cui \ids{PID}, come spiegato in
341 sez.~\ref{sec:proc_pid}, può sempre essere ottenuto con \func{getppid}; per
342 questo si ritorna un valore nullo, che non è il \ids{PID} di nessun processo.
344 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
345 sono già troppi processi nel sistema, il che di solito è sintomo che
346 qualcos'altro non sta andando per il verso giusto, o si è ecceduto il limite
347 sul numero totale di processi permessi all'utente, argomento che tratteremo in
348 dettaglio in sez.~\ref{sec:sys_resource_limit}.
350 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
351 quella in cui all'interno di un programma si creano processi figli cui viene
352 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
353 ne esegue un'altra. È il caso tipico dei programmi server (il modello
354 \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
355 padre riceve ed accetta le richieste da parte dei programmi client, per
356 ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
357 le risposte associate al servizio.
359 La seconda modalità è quella in cui il processo vuole eseguire un altro
360 programma; questo è ad esempio il caso della shell. In questo caso il processo
361 crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
362 cui parleremo in sez.~\ref{sec:proc_exec}) subito dopo la \func{fork}.
364 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
365 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
366 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
367 scelto di mantenere questa separazione, dato che, come per la prima modalità
368 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
369 aver bisogno di eseguire una \func{exec}.
371 Inoltre, anche nel caso della seconda modalità d'uso, avere le due funzioni
372 separate permette al figlio di cambiare alcune caratteristiche del processo
373 (maschera dei segnali, redirezione dell'output, utente per conto del cui viene
374 eseguito, e molto altro su cui torneremo in seguito) prima della \func{exec},
375 rendendo così relativamente facile intervenire sulle le modalità di esecuzione
379 \footnotesize \centering
380 \begin{minipage}[c]{\codesamplewidth}
381 \includecodesample{listati/fork_test.c}
384 \caption{Esempio di codice per la creazione di nuovi processi (da
385 \file{fork\_test.c}).}
386 \label{fig:proc_fork_code}
389 In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
390 di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
391 dell'uso della funzione \func{fork}. Il programma crea un numero di figli
392 specificato da linea di comando, e prende anche alcune opzioni per indicare
393 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
394 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
395 descrizione delle opzioni). Il codice completo, compresa la parte che gestisce
396 le opzioni a riga di comando, è disponibile nel file \file{fork\_test.c},
397 distribuito insieme agli altri sorgenti degli esempi della guida su
398 \url{http://gapil.gnulinux.it}.
400 Decifrato il numero di figli da creare, il ciclo principale del programma
401 (\texttt{\small 24-40}) esegue in successione la creazione dei processi figli
402 controllando il successo della chiamata a \func{fork} (\texttt{\small
403 25-29}); ciascun figlio (\texttt{\small 31-34}) si limita a stampare il
404 suo numero di successione, eventualmente attendere il numero di secondi
405 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
406 (\texttt{\small 36-38}) stampa un messaggio di creazione, eventualmente
407 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
408 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
411 Se eseguiamo il comando, che è preceduto dall'istruzione \code{export
412 LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza
413 specificare attese (come si può notare in (\texttt{\small 17-19}) i valori
414 predefiniti specificano di non attendere), otterremo come risultato sul
417 [piccardi@selidor sources]$ \textbf{export LD_LIBRARY_PATH=./; ./forktest 3}
418 Process 1963: forking 3 child
419 Spawned 1 child, pid 1964
420 Child 1 successfully executing
421 Child 1, parent 1963, exiting
423 Spawned 2 child, pid 1965
424 Child 2 successfully executing
425 Child 2, parent 1963, exiting
427 Child 3 successfully executing
428 Child 3, parent 1963, exiting
429 Spawned 3 child, pid 1966
434 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
435 si può dire quale processo fra il padre ed il figlio venga eseguito per primo
436 dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
437 primi due cicli sia stato eseguito per primo il padre (con la stampa del
438 \ids{PID} del nuovo processo) per poi passare all'esecuzione del figlio
439 (completata con i due avvisi di esecuzione ed uscita), e tornare
440 all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
441 mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
444 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
445 \textit{scheduling} usato dal kernel, dalla particolare situazione in cui si
446 trova la macchina al momento della chiamata, risultando del tutto
447 impredicibile. Eseguendo più volte il programma di prova e producendo un
448 numero diverso di figli, si sono ottenute situazioni completamente diverse,
449 compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
450 prima che uno dei figli venisse messo in esecuzione.
452 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
453 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
454 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
455 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
456 rischio di incorrere nelle cosiddette \textit{race condition} (vedi
457 sez.~\ref{sec:proc_race_cond}).
459 In realtà con l'introduzione dei kernel della serie 2.6 lo \textit{scheduler}
460 è stato modificato per eseguire sempre per primo il figlio.\footnote{i
461 risultati precedenti infatti sono stati ottenuti usando un kernel della
462 serie 2.4.} Questa è una ottimizzazione adottata per evitare che il padre,
463 effettuando per primo una operazione di scrittura in memoria, attivasse il
464 meccanismo del \textit{copy on write}, operazione inutile quando il figlio
465 viene creato solo per eseguire una \func{exec} per lanciare un altro programma
466 che scarta completamente lo spazio degli indirizzi e rende superflua la copia
467 della memoria modificata dal padre. Eseguendo sempre per primo il figlio la
468 \func{exec} verrebbe effettuata subito, con la certezza di utilizzare il
469 \textit{copy on write} solo quando necessario.
471 Con il kernel 2.6.32 però il comportamento è stato nuovamente cambiato,
472 stavolta facendo eseguire per primo sempre il padre. Si è realizzato infatti
473 che l'eventualità prospettata per la scelta precedente era comunque poco
474 probabile, mentre l'esecuzione immediata del padre presenta sempre il
475 vantaggio di poter utilizzare immediatamente tutti i dati che sono nella cache
476 della CPU e nell'unità di gestione della memoria virtuale, senza doverli
477 invalidare, cosa che per i processori moderni, che hanno linee di cache
478 interne molto profonde, avrebbe un forte impatto sulle prestazioni.
480 Allora anche se quanto detto in precedenza vale come comportamento effettivo
481 dei programmi soltanto per i kernel fino alla serie 2.4, per mantenere la
482 portabilità con altri kernel unix-like, e con i diversi comportamenti adottati
483 dalle Linux nella sua evoluzione, è comunque opportuno non fare affidamento su
484 nessun tipo di comportamento predefinito e non fare assunzioni sull'ordine di
485 esecuzione di padre e figlio.
487 Si noti infine come dopo la \func{fork}, essendo i segmenti di memoria
488 utilizzati dai singoli processi completamente indipendenti, le modifiche delle
489 variabili nei processi figli, come l'incremento di \var{i} in (\texttt{\small
490 31}), sono visibili solo a loro, (ogni processo vede solo la propria copia
491 della memoria), e non hanno alcun effetto sul valore che le stesse variabili
492 hanno nel processo padre ed in eventuali altri processi figli che eseguano lo
495 Un secondo aspetto molto importante nella creazione dei processi figli è
496 quello dell'interazione dei vari processi con i file. Ne parleremo qui anche
497 se buona parte dei concetti relativi ai file verranno trattati più avanti
498 (principalmente in sez.~\ref{sec:file_unix_interface}). Per illustrare meglio
499 quello che avviene si può redirigere su un file l'output del programma di
500 test, quello che otterremo è:
502 [piccardi@selidor sources]$ \textbf{./forktest 3 > output}
503 [piccardi@selidor sources]$ \textbf{cat output}
504 Process 1967: forking 3 child
505 Child 1 successfully executing
506 Child 1, parent 1967, exiting
507 Test for forking 3 child
508 Spawned 1 child, pid 1968
510 Child 2 successfully executing
511 Child 2, parent 1967, exiting
512 Test for forking 3 child
513 Spawned 1 child, pid 1968
515 Spawned 2 child, pid 1969
517 Child 3 successfully executing
518 Child 3, parent 1967, exiting
519 Test for forking 3 child
520 Spawned 1 child, pid 1968
522 Spawned 2 child, pid 1969
524 Spawned 3 child, pid 1970
527 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
529 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
530 in gran dettaglio in sez.~\ref{sec:file_unix_interface} per l'interfaccia
531 nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione
532 adottata nelle librerie del linguaggio C, valida per qualunque sistema
535 Qui basta accennare che si sono usate le funzioni standard della libreria del
536 C che prevedono l'output bufferizzato. Il punto è che questa bufferizzazione
537 (che tratteremo in dettaglio in sez.~\ref{sec:file_buffering}) varia a seconda
538 che si tratti di un file su disco, in cui il buffer viene scaricato su disco
539 solo quando necessario, o di un terminale, in cui il buffer viene scaricato ad
540 ogni carattere di ``a capo''.
542 Nel primo esempio allora avevamo che, essendovi un a capo nella stringa
543 stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui
544 le singole righe comparivano a video subito dopo l'esecuzione della
545 \func{printf}. Ma con la redirezione su file la scrittura non avviene più alla
546 fine di ogni riga e l'output resta nel buffer.
548 Dato che ogni figlio riceve una copia della memoria del padre, esso riceverà
549 anche quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte
550 dal padre fino allora. Così quando il buffer viene scritto su disco all'uscita
551 del figlio, troveremo nel file anche tutto quello che il processo padre aveva
552 scritto prima della sua creazione. E alla fine del file (dato che in questo
553 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
555 L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
556 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
557 solo processi diversi possono scrivere in contemporanea sullo stesso file
558 (l'argomento dell'accesso concorrente ai file è trattato in dettaglio in
559 sez.~\ref{sec:file_shared_access}), ma anche che, a differenza di quanto
560 avviene per le variabili in memoria, la posizione corrente sul file è
561 condivisa fra il padre e tutti i processi figli.
563 Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
564 così il file su cui di default un programma scrive i suoi dati in uscita,
565 tratteremo l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} del padre
566 viene rediretto come si è fatto nell'esempio, lo stesso avviene anche per
567 tutti i figli. La funzione \func{fork} infatti ha la caratteristica di
568 duplicare nei processi figli tutti i \textit{file descriptor} (vedi
569 sez.~\ref{sec:file_fd}) dei file aperti nel processo padre (allo stesso modo
570 in cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}). Ciò
571 fa si che padre e figli condividano le stesse voci della \textit{file table}
572 (tratteremo in dettaglio questi termini in sez.~\ref{sec:file_fd} e
573 sez.~\ref{sec:file_shared_access}) fra le quali c'è anche la posizione
576 Quando un processo scrive su un file la posizione corrente viene aggiornata
577 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
578 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
579 casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
580 file, che l'output di un processo successivo vada a sovrapporsi a quello dei
581 precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
582 perdute per via di una sovrascrittura.
584 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
585 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
586 scrivono sullo stesso file. Un caso tipico di questo comportamento è la shell
587 quando lancia un programma. In questo modo, anche se lo standard output viene
588 rediretto, il padre potrà sempre continuare a scrivere in coda a quanto
589 scritto dal figlio in maniera automatica; se così non fosse ottenere questo
590 comportamento sarebbe estremamente complesso necessitando di una qualche forma
591 di comunicazione fra i due processi per far riprendere al padre la scrittura
594 In generale comunque non è buona norma far scrivere più processi sullo stesso
595 file senza una qualche forma di sincronizzazione in quanto, come visto anche
596 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
597 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
598 i file dopo una \func{fork} sono sostanzialmente due:
600 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
601 è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
602 della posizione corrente dopo eventuali operazioni di lettura e scrittura
603 effettuate dal figlio è automatica.
604 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
605 ciascuno dei due processi deve chiudere i file che non gli servono una volta
606 che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
609 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
610 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
611 comune dopo l'esecuzione di una \func{fork} è la seguente:
613 \item i file aperti e gli eventuali flag di \textit{close-on-exec} impostati
614 (vedi sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl_ioctl});
615 \item gli identificatori per il controllo di accesso: l'\textsl{user-ID
616 reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
617 \textsl{group-ID effettivo} ed i \textsl{group-ID supplementari} (vedi
618 sez.~\ref{sec:proc_access_id});
619 \item gli identificatori per il controllo di sessione: il \textit{process
620 group-ID} e il \textit{session id} ed il terminale di controllo (vedi
621 sez.~\ref{sec:sess_proc_group});
622 \item la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la
623 directory radice (vedi sez.~\ref{sec:file_chroot});
624 \item la maschera dei permessi di creazione dei file (vedi
625 sez.~\ref{sec:file_perm_management});
626 \item la maschera dei segnali bloccati (vedi
627 sez.~\ref{sec:sig_sigmask}) e le azioni installate (vedi
628 sez.~\ref{sec:sig_gen_beha});
629 \item i segmenti di memoria condivisa agganciati al processo (vedi
630 sez.~\ref{sec:ipc_sysv_shm});
631 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
632 \item il valori di \textit{nice}, le priorità \textit{real-time} e le affinità
633 di processore (vedi sez.~\ref{sec:proc_sched_stand},
634 sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
635 \item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
636 \item l'insieme dei descrittori associati alle code di messaggi POSIX (vedi
637 sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i \textit{file
638 descriptor}, questo significa che entrambi condivideranno gli stessi flag.
641 Oltre a quelle relative ad un diverso spazio degli indirizzi (e una memoria
642 totalmente indipendente) le differenze fra padre e figlio dopo l'esecuzione di
643 una \func{fork} invece sono:\footnote{a parte le ultime quattro, relative a
644 funzionalità specifiche di Linux, le altre sono esplicitamente menzionate
645 dallo standard POSIX.1-2001.}
647 \item il valore di ritorno di \func{fork};
648 \item il \ids{PID} (\textit{process id}), quello del figlio viene assegnato ad
649 un nuovo valore univoco;
650 \item il \ids{PPID} (\textit{parent process id}), quello del figlio viene
651 impostato al \ids{PID} del padre;
652 \item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e
653 delle risorse usate (vedi sez.~\ref{sec:sys_resource_use}), che nel figlio
655 \item i \textit{lock} sui file (vedi sez.~\ref{sec:file_locking}) e sulla
656 memoria (vedi sez.~\ref{sec:proc_mem_lock}), che non vengono ereditati dal
658 \item gli allarmi, i timer (vedi sez.~\ref{sec:sig_alarm_abort}) ed i segnali
659 pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che per il figlio vengono
661 \item le operazioni di I/O asincrono in corso (vedi
662 sez.~\ref{sec:file_asyncronous_io}) che non vengono ereditate dal figlio;
663 \item gli aggiustamenti fatti dal padre ai semafori con \func{semop} (vedi
664 sez.~\ref{sec:ipc_sysv_sem}).
665 \item le notifiche sui cambiamenti delle directory con \textit{dnotify} (vedi
666 sez.~\ref{sec:sig_notification}), che non vengono ereditate dal figlio;
667 \item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi
668 sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
669 \item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:process_prctl}) che
670 notifica al figlio la terminazione del padre viene cancellata se presente
672 \item il segnale di terminazione del figlio è sempre \signal{SIGCHLD} anche
673 qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}).
676 Una seconda funzione storica usata per la creazione di un nuovo processo è
677 \funcm{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
678 semantica e gli stessi errori; la sola differenza è che non viene creata la
679 tabella delle pagine né la struttura dei task per il nuovo processo. Il
680 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
681 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
682 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
683 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
685 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
686 \func{fork} comportava anche la copia completa del segmento dati del processo
687 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
688 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
689 venne introdotta in BSD per migliorare le prestazioni.
691 Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
692 assolutamente trascurabile, e l'uso di questa funzione, che resta un caso
693 speciale della \textit{system call} \func{clone} (che tratteremo in dettaglio
694 in sez.~\ref{sec:process_clone}) è deprecato; per questo eviteremo di
695 trattarla ulteriormente.
698 \subsection{La conclusione di un processo}
699 \label{sec:proc_termination}
701 In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
702 chiudere un programma, ma dall'interno del programma stesso. Avendo a che fare
703 con un sistema \textit{multitasking} resta da affrontare l'argomento dal punto
704 di vista di come il sistema gestisce la conclusione dei processi.
706 Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
707 programma viene terminato in maniera normale: la chiamata di \func{exit}, che
708 esegue le funzioni registrate per l'uscita e chiude gli \textit{stream} e poi
709 esegue \func{\_exit}, il ritorno dalla funzione \code{main} equivalente alla
710 chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
711 direttamente alle operazioni di terminazione del processo da parte del kernel.
713 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
714 modalità di conclusione anomala. Queste sono in sostanza due: il programma può
715 chiamare la funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}) per
716 invocare una chiusura anomala, o essere terminato da un segnale (torneremo sui
717 segnali in cap.~\ref{cha:signals}). In realtà anche la prima modalità si
718 riconduce alla seconda, dato che \func{abort} si limita a generare il segnale
721 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
722 comunque una serie di operazioni di terminazione: chiude tutti i file aperti,
723 rilascia la memoria che stava usando, e così via; l'elenco completo delle
724 operazioni eseguite alla chiusura di un processo è il seguente:
726 \item tutti i \textit{file descriptor} (vedi sez.~\ref{sec:file_fd}) sono
728 \item viene memorizzato lo stato di terminazione del processo;
729 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
731 \item viene inviato il segnale \signal{SIGCHLD} al processo padre (vedi
732 sez.~\ref{sec:sig_sigchld});
733 \item se il processo è un leader di sessione ed il suo terminale di controllo
734 è quello della sessione viene mandato un segnale di \signal{SIGHUP} a tutti i
735 processi del gruppo di \textit{foreground} e il terminale di controllo viene
736 disconnesso (vedi sez.~\ref{sec:sess_ctrl_term});
737 \item se la conclusione di un processo rende orfano un \textit{process
738 group} ciascun membro del gruppo viene bloccato, e poi gli vengono
739 inviati in successione i segnali \signal{SIGHUP} e \signal{SIGCONT}
740 (vedi ancora sez.~\ref{sec:sess_ctrl_term}).
743 \itindbeg{termination~status}
745 Oltre queste operazioni è però necessario poter disporre di un meccanismo
746 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
747 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
748 scelto consiste nel riportare lo \textsl{stato di terminazione} (il cosiddetto
749 \textit{termination status}) al processo padre.
751 Nel caso di conclusione normale, abbiamo visto in
752 sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
753 caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
754 valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
755 valore di ritorno per \code{main}. Ma se il processo viene concluso in
756 maniera anomala il programma non può specificare nessun \textit{exit status},
757 ed è il kernel che deve generare autonomamente il \textit{termination status}
758 per indicare le ragioni della conclusione anomala.
760 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
761 quello che contraddistingue lo stato di chiusura del processo e viene
762 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
763 sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione
764 normale il kernel usa il primo (nel codice eseguito da \func{\_exit}) per
767 La scelta di riportare al padre lo stato di terminazione dei figli, pur
768 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
769 alla sua creazione è scontato che ogni nuovo processo abbia un padre, non è
770 detto che sia così alla sua conclusione, dato che il padre potrebbe essere già
771 terminato; si potrebbe avere cioè quello che si chiama un processo
774 Questa complicazione viene superata facendo in modo che il processo orfano
775 venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \ids{PID} 1,
776 cioè quello lanciato direttamente dal kernel all'avvio, che sta alla base
777 dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy} e che anche
778 per questo motivo ha un ruolo essenziale nel sistema e non può mai
779 terminare.\footnote{almeno non senza un blocco completo del sistema, in caso
780 di terminazione o di non esecuzione di \cmd{init} infatti il kernel si
781 blocca con un cosiddetto \textit{kernel panic}, dato che questo è un errore
784 Come già accennato quando un processo termina, il kernel controlla se è il
785 padre di altri processi in esecuzione: in caso positivo allora il \ids{PPID}
786 di tutti questi processi verrà sostituito dal kernel con il \ids{PID} di
787 \cmd{init}, cioè con 1. In questo modo ogni processo avrà sempre un padre (nel
788 caso possiamo parlare di un padre \textsl{adottivo}) cui riportare il suo
789 stato di terminazione.
791 Come verifica di questo comportamento possiamo eseguire il nostro programma
792 \cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima
793 di uscire, il risultato è:
795 [piccardi@selidor sources]$ \textbf{./forktest -c2 3}
796 Process 1972: forking 3 child
797 Spawned 1 child, pid 1973
798 Child 1 successfully executing
800 Spawned 2 child, pid 1974
801 Child 2 successfully executing
803 Child 3 successfully executing
804 Spawned 3 child, pid 1975
807 [piccardi@selidor sources]$ Child 3, parent 1, exiting
808 Child 2, parent 1, exiting
809 Child 1, parent 1, exiting
811 come si può notare in questo caso il processo padre si conclude prima dei
812 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
813 secondi dopo viene stampato a video anche l'output dei tre figli che
814 terminano, e come si può notare in questo caso, al contrario di quanto visto
815 in precedenza, essi riportano 1 come \ids{PPID}.
817 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
818 perché non è detto che il padre possa ricevere immediatamente lo stato di
819 terminazione, quindi il kernel deve comunque conservare una certa quantità di
820 informazioni riguardo ai processi che sta terminando.
822 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
823 memorizzando alcuni dati essenziali, come il \ids{PID}, i tempi di CPU usati
824 dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
825 mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente.
829 I processi che sono terminati, ma il cui stato di terminazione non è stato
830 ancora ricevuto dal padre sono chiamati \textit{zombie}, essi restano presenti
831 nella tabella dei processi ed in genere possono essere identificati
832 dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella colonna che ne
833 indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando il padre
834 effettuerà la lettura dello stato di terminazione anche questa informazione,
835 non più necessaria, verrà scartata ed il processo potrà considerarsi
836 completamente concluso.
838 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
839 condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi
840 sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10
841 secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso
842 terminale (prima dello scadere dei 10 secondi) otterremo:
844 [piccardi@selidor sources]$ \textbf{ps T}
845 PID TTY STAT TIME COMMAND
846 419 pts/0 S 0:00 bash
847 568 pts/0 S 0:00 ./forktest -e10 3
848 569 pts/0 Z 0:00 [forktest <defunct>]
849 570 pts/0 Z 0:00 [forktest <defunct>]
850 571 pts/0 Z 0:00 [forktest <defunct>]
851 572 pts/0 R 0:00 ps T
854 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
855 terminazione, i tre processi figli sono ancora presenti pur essendosi
856 conclusi, con lo stato di \textit{zombie} e l'indicazione che sono terminati
857 (la scritta \texttt{defunct}).
859 La possibilità di avere degli \textit{zombie} deve essere tenuta sempre
860 presente quando si scrive un programma che deve essere mantenuto in esecuzione
861 a lungo e creare molti processi figli. In questo caso si deve sempre avere
862 cura di far leggere al programma l'eventuale stato di uscita di tutti i
863 figli. Una modalità comune di farlo è attraverso l'utilizzo di un apposito
864 \textit{signal handler} che chiami la funzione \func{wait}, (vedi
865 sez.~\ref{sec:proc_wait}), ne esamineremo in dettaglio un esempio
866 (fig.~\ref{fig:sig_sigchld_handl}) in sez.~\ref{sec:sig_sigchld}.
868 La lettura degli stati di uscita è necessaria perché anche se gli
869 \textit{zombie} non consumano risorse di memoria o processore, occupano
870 comunque una voce nella tabella dei processi e se li si lasciano accumulare a
871 lungo quest'ultima potrebbe esaurirsi, con la conseguente impossibilità di
872 lanciare nuovi processi.
874 Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non
875 diviene mai uno \textit{zombie}. Questo perché una delle funzioni di
876 \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i processi
877 a cui fa da padre, completandone la terminazione. Questo è quanto avviene
878 anche quando, come nel caso del precedente esempio con \cmd{forktest}, il
879 padre termina con dei figli in stato di \textit{zombie}. Questi scompaiono
880 quando, alla terminazione del padre dopo i secondi programmati, tutti figli
881 che avevamo generato, e che erano diventati \textit{zombie}, vengono adottati
882 da \cmd{init}, il quale provvede a completarne la terminazione.
884 Si tenga presente infine che siccome gli \textit{zombie} sono processi già
885 terminati, non c'è modo di eliminarli con il comando \cmd{kill} o inviandogli
886 un qualunque segnale di terminazione (l'argomento è trattato in
887 sez.~\ref{sec:sig_termination}). Qualora ci si trovi in questa situazione
888 l'unica possibilità di cancellarli dalla tabella dei processi è quella di
889 terminare il processo che li ha generati e che non sta facendo il suo lavoro,
890 in modo che \cmd{init} possa adottarli e concluderne correttamente la
893 Si tenga anche presente che la presenza di \textit{zombie} nella tabella dei
894 processi non è sempre indice di un qualche malfunzionamento, in una macchina
895 con molto carico infatti può esservi una presenza temporanea dovuta al fatto
896 che il processo padre ancora non ha avuto il tempo di gestirli.
901 \subsection{Le funzioni di attesa e ricezione degli stati di uscita}
902 \label{sec:proc_wait}
904 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
905 consiste nella creazione di programmi di tipo server, in cui un processo
906 principale attende le richieste che vengono poi soddisfatte da una serie di
909 Si è già sottolineato al paragrafo precedente come in questo caso diventi
910 necessario gestire esplicitamente la conclusione dei figli onde evitare di
911 riempire di \textit{zombie} la tabella dei processi. Tratteremo in questa
912 sezione le funzioni di sistema deputate a questo compito; la prima è
913 \funcd{wait} ed il suo prototipo è:
918 \fdecl{pid\_t wait(int *status)}
919 \fdesc{Attende la terminazione di un processo.}
921 {La funzione ritorna il \ids{PID} del figlio in caso di successo e $-1$ per un
922 errore, nel qual caso \var{errno} assumerà uno dei valori:
924 \item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere
925 uno stato di terminazione.
926 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
930 Questa funzione è presente fin dalle prime versioni di Unix ed è quella usata
931 tradizionalmente per attendere la terminazione dei figli. La funzione sospende
932 l'esecuzione del processo corrente e ritorna non appena un qualunque processo
933 figlio termina. Se un figlio è già terminato prima della sua chiamata la
934 funzione ritorna immediatamente, se più processi figli sono già terminati
935 occorrerà continuare a chiamare la funzione più volte fintanto che non si è
936 recuperato lo stato di terminazione di tutti quanti.
938 Al ritorno della funzione lo stato di terminazione del figlio viene salvato
939 (come \textit{value result argument}) nella variabile puntata
940 da \param{status} e tutte le risorse del kernel relative al processo (vedi
941 sez.~\ref{sec:proc_termination}) vengono rilasciate. Nel caso un processo
942 abbia più figli il valore di ritorno della funzione sarà impostato al
943 \ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa che
944 permette di identificare qual è il figlio che è terminato.
946 \itindend{termination~status}
948 Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
949 all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
950 necessario attendere la conclusione di uno specifico processo fra tutti quelli
951 esistenti occorre predisporre un meccanismo che tenga conto di tutti processi
952 che sono terminati, e provveda a ripetere la chiamata alla funzione nel caso
953 il processo cercato non risulti fra questi. Se infatti il processo cercato è
954 già terminato e se è già ricevuto lo stato di uscita senza registrarlo, la
955 funzione non ha modo di accorgersene, e si continuerà a chiamarla senza
956 accorgersi che quanto interessava è già accaduto.
958 Per questo motivo lo standard POSIX.1 ha introdotto una seconda funzione che
959 effettua lo stesso servizio, ma dispone di una serie di funzionalità più
960 ampie, legate anche al controllo di sessione (si veda
961 sez.~\ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
962 comportamento di \func{wait}\footnote{in effetti il codice
963 \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
964 \&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione di
965 sistema, \funcd{waitpid}, il cui prototipo è:
970 \fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
971 \fdesc{Attende il cambiamento di stato di un processo figlio.}
973 {La funzione ritorna il \ids{PID} del processo che ha cambiato stato in caso
974 di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il
975 processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
976 assumerà uno dei valori:
978 \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
979 non è figlio del processo chiamante.
980 \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
981 la funzione è stata interrotta da un segnale.
982 \item[\errcode{EINVAL}] si è specificato un valore non valido per
983 l'argomento \param{options}.
987 La prima differenza fra le due funzioni è che con \func{waitpid} si può
988 specificare in maniera flessibile quale processo attendere, sulla base del
989 valore fornito dall'argomento \param{pid}, questo può assumere diversi valori,
990 secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}, dove si
991 sono riportate anche le costanti definite per indicare alcuni di essi.
996 \begin{tabular}[c]{|c|c|p{8cm}|}
998 \textbf{Valore} & \textbf{Costante} &\textbf{Significato}\\
1001 $<-1$& -- & Attende per un figlio il cui \textit{process
1002 group} (vedi sez.~\ref{sec:sess_proc_group}) è
1003 uguale al valore assoluto di \param{pid}.\\
1004 $-1$&\constd{WAIT\_ANY} & Attende per un figlio qualsiasi, usata in
1005 questa maniera senza specificare nessuna opzione
1006 è equivalente a \func{wait}.\\
1007 $ 0$&\constd{WAIT\_MYPGRP}&Attende per un figlio il cui \textit{process
1008 group} (vedi sez.~\ref{sec:sess_proc_group}) è
1009 uguale a quello del processo chiamante.\\
1010 $>0$& -- & Attende per un figlio il cui \ids{PID} è uguale
1011 al valore di \param{pid}.\\
1014 \caption{Significato dei valori dell'argomento \param{pid} della funzione
1016 \label{tab:proc_waidpid_pid}
1019 Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
1020 funzione delle opportune opzioni tramite l'argomento \param{options}; questo
1021 deve essere specificato come maschera binaria delle costanti riportati nella
1022 prima parte in tab.~\ref{tab:proc_waitpid_options} che possono essere
1023 combinate fra loro con un OR aritmetico. Nella seconda parte della stessa
1024 tabella si sono riportati anche alcune opzioni non standard specifiche di
1025 Linux, che consentono un controllo più dettagliato per i processi creati con
1026 la \textit{system call} generica \func{clone} (vedi
1027 sez.~\ref{sec:process_clone}) e che vengono usati principalmente per la
1028 gestione della terminazione dei \textit{thread} (vedi
1029 sez.~\ref{sec:thread_xxx}).
1034 \begin{tabular}[c]{|l|p{8cm}|}
1036 \textbf{Costante} & \textbf{Descrizione}\\
1039 \const{WNOHANG} & La funzione ritorna immediatamente anche se non è
1040 terminato nessun processo figlio.\\
1041 \const{WUNTRACED} & Ritorna anche quando un processo figlio è stato
1043 \const{WCONTINUED}& Ritorna anche quando un processo figlio che era stato
1044 fermato ha ripreso l'esecuzione (disponibile solo a
1045 partire dal kernel 2.6.10).\\
1047 \constd{\_\_WCLONE}& Attende solo per i figli creati con \func{clone}
1048 (vedi sez.~\ref{sec:process_clone}), vale a dire
1049 processi che non emettono nessun segnale
1050 o emettono un segnale diverso da \signal{SIGCHLD} alla
1051 terminazione, il default è attendere soltanto i
1052 processi figli ordinari ignorando quelli creati da
1054 \constd{\_\_WALL} & Attende per qualunque figlio, sia ordinario che creato
1055 con \func{clone}, se specificata insieme a
1056 \const{\_\_WCLONE} quest'ultima viene ignorata. \\
1057 \constd{\_\_WNOTHREAD}& Non attende per i figli di altri \textit{thread}
1058 dello stesso \textit{thread group}, questo era il
1059 comportamento di default del kernel 2.4 che non
1060 supportava la possibilità, divenuta il default a
1061 partire dal 2.6, di attendere un qualunque figlio
1062 appartenente allo stesso \textit{thread group}. \\
1065 \caption{Costanti che identificano i bit dell'argomento \param{options}
1066 della funzione \func{waitpid}.}
1067 \label{tab:proc_waitpid_options}
1072 L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
1073 funzione qualora nessun figlio sia uscito o non si siano verificate le altre
1074 condizioni per l'uscita della funzione. in tal caso. In tal caso la funzione,
1075 invece di restituire il \ids{PID} del processo (che è sempre un intero
1076 positivo) ritornerà un valore nullo.
1079 \constbeg{WUNTRACED}
1080 \constbeg{WCONTINUED}
1082 Le altre due opzioni, \const{WUNTRACED} e \const{WCONTINUED}, consentono
1083 rispettivamente di tracciare non la terminazione di un processo, ma il fatto
1084 che esso sia stato fermato, o fatto ripartire, e sono utilizzate per la
1085 gestione del controllo di sessione (vedi sez.~\ref{sec:sess_job_control}).
1087 Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \ids{PID},
1088 quando un processo figlio entra nello stato \textit{stopped}\footnote{in
1089 realtà viene notificato soltanto il caso in cui il processo è stato fermato
1090 da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
1091 cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi
1092 sez.~\ref{sec:process_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}),
1093 mentre con \const{WCONTINUED} la funzione ritorna quando un processo in stato
1094 \textit{stopped} riprende l'esecuzione per la ricezione del segnale
1095 \signal{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
1096 trattato in sez.~\ref{sec:sess_ctrl_term}).
1098 \constend{WUNTRACED}
1099 \constend{WCONTINUED}
1101 La terminazione di un processo figlio (così come gli altri eventi osservabili
1102 con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
1103 di un programma e può avvenire in un qualunque momento. Per questo motivo,
1104 come accennato nella sezione precedente, una delle azioni prese dal kernel
1105 alla conclusione di un processo è quella di mandare un segnale di
1106 \signal{SIGCHLD} al padre. L'azione predefinita (si veda
1107 sez.~\ref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
1108 generazione costituisce il meccanismo di comunicazione asincrona con cui il
1109 kernel avverte il processo padre che uno dei suoi figli è terminato.
1111 Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
1112 al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
1113 standard POSIX.1-2001 e come da esso richiesto se \signal{SIGCHLD} viene
1114 ignorato, o se si imposta il flag di \const{SA\_NOCLDSTOP} nella ricezione
1115 dello stesso (si veda sez.~\ref{sec:sig_sigaction}) i processi figli che
1116 terminano non diventano \textit{zombie} e sia \func{wait} che \func{waitpid}
1117 si bloccano fintanto che tutti i processi figli non sono terminati, dopo di
1118 che falliscono con un errore di \errcode{ENOCHLD}.\footnote{questo è anche il
1119 motivo per cui le opzioni \const{WUNTRACED} e \const{WCONTINUED} sono
1120 utilizzabili soltanto qualora non si sia impostato il flag di
1121 \const{SA\_NOCLDSTOP} per il segnale \signal{SIGCHLD}.}
1123 Con i kernel della serie 2.4 e tutti i kernel delle serie precedenti entrambe
1124 le funzioni di attesa ignorano questa prescrizione e si comportano sempre
1125 nello stesso modo,\footnote{lo standard POSIX.1 originale infatti lascia
1126 indefinito il comportamento di queste funzioni quando \signal{SIGCHLD} viene
1127 ignorato.} indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno:
1128 attendono la terminazione di un processo figlio e ritornano il relativo
1129 \ids{PID} e lo stato di terminazione nell'argomento \param{status}.
1131 In generale in un programma non si vuole essere forzati ad attendere la
1132 conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
1133 questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
1134 la presenza di \textit{zombie}). Per questo la modalità più comune di
1135 chiamare queste funzioni è quella di utilizzarle all'interno di un
1136 \textit{signal handler} (vedremo un esempio di come gestire \signal{SIGCHLD}
1137 con i segnali in sez.~\ref{sec:sig_example}). In questo caso infatti, dato che
1138 il segnale è generato dalla terminazione di un figlio, avremo la certezza che
1139 la chiamata a \func{waitpid} non si bloccherà.
1141 Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di
1142 terminazione del processo tramite il puntatore \param{status}, e se non
1143 interessa memorizzare lo stato si può passare un puntatore nullo. Il valore
1144 restituito da entrambe le funzioni dipende dall'implementazione, ma
1145 tradizionalmente gli 8 bit meno significativi sono riservati per memorizzare
1146 lo stato di uscita del processo, e gli altri per indicare il segnale che ha
1147 causato la terminazione (in caso di conclusione anomala), uno per indicare se
1148 è stato generato un \textit{core dump} (vedi sez.~\ref{sec:sig_standard}),
1149 ecc.\footnote{le definizioni esatte si possono trovare in
1150 \file{<bits/waitstatus.h>} ma questo file non deve mai essere usato
1151 direttamente, esso viene incluso attraverso \file{<sys/wait.h>}.}
1156 \begin{tabular}[c]{|l|p{10cm}|}
1158 \textbf{Macro} & \textbf{Descrizione}\\
1161 \macrod{WIFEXITED}\texttt{(s)} & Condizione vera (valore non nullo) per
1162 un processo figlio che sia terminato
1164 \macrod{WEXITSTATUS}\texttt{(s)} & Restituisce gli otto bit meno
1165 significativi dello stato di uscita del
1166 processo (passato attraverso
1167 \func{\_exit}, \func{exit} o come valore
1168 di ritorno di \code{main}); può essere
1169 valutata solo se \val{WIFEXITED} ha
1170 restituito un valore non nullo.\\
1171 \macrod{WIFSIGNALED}\texttt{(s)} & Condizione vera se il processo figlio è
1172 terminato in maniera anomala a causa di
1173 un segnale che non è stato catturato
1174 (vedi sez.~\ref{sec:sig_notification}).\\
1175 \macrod{WTERMSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
1176 causato la terminazione anomala del
1177 processo; può essere valutata solo se
1178 \val{WIFSIGNALED} ha restituito un
1180 \macrod{WCOREDUMP}\texttt{(s)} & Vera se il processo terminato ha
1182 \textit{core dump}; può essere valutata
1183 solo se \val{WIFSIGNALED} ha restituito
1184 un valore non nullo.\footnotemark \\
1185 \macrod{WIFSTOPPED}\texttt{(s)} & Vera se il processo che ha causato il
1186 ritorno di \func{waitpid} è bloccato;
1187 l'uso è possibile solo con
1188 \func{waitpid} avendo specificato
1189 l'opzione \const{WUNTRACED}.\\
1190 \macrod{WSTOPSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
1191 bloccato il processo; può essere
1192 valutata solo se \val{WIFSTOPPED} ha
1193 restituito un valore non nullo. \\
1194 \macrod{WIFCONTINUED}\texttt{(s)}& Vera se il processo che ha causato il
1195 ritorno è stato riavviato da un
1196 \signal{SIGCONT} (disponibile solo a
1197 partire dal kernel 2.6.10).\\
1200 \caption{Descrizione delle varie macro di preprocessore utilizzabili per
1201 verificare lo stato di terminazione \var{s} di un processo.}
1202 \label{tab:proc_status_macro}
1205 \footnotetext{questa macro non è definita dallo standard POSIX.1-2001, ma è
1206 presente come estensione sia in Linux che in altri Unix, deve essere
1207 pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
1208 blocco \texttt{\#ifdef WCOREDUMP ... \#endif}.}
1210 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
1211 analizzare lo stato di uscita. Esse sono definite sempre in
1212 \file{<sys/wait.h>} ed elencate in tab.~\ref{tab:proc_status_macro}. Si tenga
1213 presente che queste macro prevedono che gli si passi come parametro la
1214 variabile di tipo \ctyp{int} puntata dall'argomento \param{status} restituito
1215 da \func{wait} o \func{waitpid}.
1217 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1218 \val{WTERMSIG} può essere confrontato con le costanti che identificano i
1219 segnali definite in \headfile{signal.h} ed elencate in
1220 tab.~\ref{tab:sig_signal_list}, e stampato usando le apposite funzioni
1221 trattate in sez.~\ref{sec:sig_strsignal}.
1223 A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
1224 stata introdotta una nuova funzione di attesa che consente di avere un
1225 controllo molto più preciso sui possibili cambiamenti di stato dei processi
1226 figli e più dettagli sullo stato di uscita; la funzione di sistema è
1227 \funcd{waitid} ed il suo prototipo è:
1232 \fdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int options)}
1233 \fdesc{Attende il cambiamento di stato di un processo figlio.}
1235 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1236 caso \var{errno} assumerà uno dei valori:
1238 \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
1239 non è figlio del processo chiamante.
1240 \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
1241 la funzione è stata interrotta da un segnale.
1242 \item[\errcode{EINVAL}] si è specificato un valore non valido per
1243 l'argomento \param{options}.
1247 La funzione prevede che si specifichi quali processi si intendono osservare
1248 usando i due argomenti \param{idtype} ed \param{id}; il primo indica se ci si
1249 vuole porre in attesa su un singolo processo, un gruppo di processi o un
1250 processo qualsiasi, e deve essere specificato secondo uno dei valori di
1251 tab.~\ref{tab:proc_waitid_idtype}; il secondo indica, a seconda del valore del
1252 primo, quale processo o quale gruppo di processi selezionare.
1257 \begin{tabular}[c]{|l|p{8cm}|}
1259 \textbf{Valore} & \textbf{Descrizione}\\
1262 \constd{P\_PID} & Indica la richiesta di attendere per un processo figlio
1263 il cui \ids{PID} corrisponda al valore dell'argomento
1265 \constd{P\_PGID}& Indica la richiesta di attendere per un processo figlio
1266 appartenente al \textit{process group} (vedi
1267 sez.~\ref{sec:sess_proc_group}) il cui \acr{pgid}
1268 corrisponda al valore dell'argomento \param{id}.\\
1269 \constd{P\_ALL} & Indica la richiesta di attendere per un processo figlio
1270 generico, il valore dell'argomento \param{id} viene
1274 \caption{Costanti per i valori dell'argomento \param{idtype} della funzione
1276 \label{tab:proc_waitid_idtype}
1279 Come per \func{waitpid} anche il comportamento di \func{waitid} è
1280 controllato dall'argomento \param{options}, da specificare come maschera
1281 binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
1282 alcuni di questi siano identici come significato ed effetto ai precedenti di
1283 tab.~\ref{tab:proc_waitpid_options}, ci sono delle differenze significative:
1284 in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
1285 di un processo impostando l'opzione \const{WEXITED}, mentre il precedente
1286 \const{WUNTRACED} è sostituito da \const{WSTOPPED}. Infine è stata aggiunta
1287 l'opzione \const{WNOWAIT} che consente una lettura dello stato mantenendo il
1288 processo in attesa di ricezione, così che una successiva chiamata possa di
1289 nuovo riceverne lo stato.
1294 \begin{tabular}[c]{|l|p{8cm}|}
1296 \textbf{Valore} & \textbf{Descrizione}\\
1299 \constd{WEXITED} & Ritorna quando un processo figlio è terminato.\\
1300 \constd{WNOHANG} & Ritorna immediatamente anche se non c'è niente da
1302 \constd{WSTOPPED} & Ritorna quando un processo figlio è stato fermato.\\
1303 \const{WCONTINUED} & Ritorna quando un processo figlio che era stato
1304 fermato ha ripreso l'esecuzione.\\
1305 \constd{WNOWAIT} & Lascia il processo ancora in attesa di ricezione, così
1306 che una successiva chiamata possa di nuovo riceverne
1310 \caption{Costanti che identificano i bit dell'argomento \param{options}
1311 della funzione \func{waitid}.}
1312 \label{tab:proc_waitid_options}
1315 La funzione \func{waitid} restituisce un valore nullo in caso di successo, e
1316 $-1$ in caso di errore; viene restituito un valore nullo anche se è stata
1317 specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
1318 senza che nessun figlio sia terminato. Pertanto per verificare il motivo del
1319 ritorno della funzione occorre analizzare le informazioni che essa
1320 restituisce; queste, al contrario delle precedenti \func{wait} e
1321 \func{waitpid} che usavano un semplice valore numerico, sono ritornate in una
1322 struttura di tipo \struct{siginfo\_t} (vedi fig.~\ref{fig:sig_siginfo_t})
1323 all'indirizzo puntato dall'argomento \param{infop}.
1325 Tratteremo nei dettagli la struttura \struct{siginfo\_t} ed il significato dei
1326 suoi vari campi in sez.~\ref{sec:sig_sigaction}, per quanto ci interessa qui
1327 basta dire che al ritorno di \func{waitid} verranno avvalorati i seguenti
1329 \begin{basedescript}{\desclabelwidth{1.8cm}}
1330 \item[\var{si\_pid}] con il \ids{PID} del figlio.
1331 \item[\var{si\_uid}] con l'\textsl{user-ID reale} (vedi
1332 sez.~\ref{sec:proc_perms}) del figlio.
1333 \item[\var{si\_signo}] con \signal{SIGCHLD}.
1334 \item[\var{si\_status}] con lo stato di uscita del figlio o con il segnale che
1335 lo ha terminato, fermato o riavviato.
1336 \item[\var{si\_code}] con uno fra \const{CLD\_EXITED}, \const{CLD\_KILLED},
1337 \const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
1338 \const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
1339 significato è, nell'ordine: uscita normale, terminazione da segnale,
1340 processo fermato, processo riavviato, processo terminato in
1341 \textit{core dump} (vedi sez.~\ref{sec:sig_standard}).
1344 Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
1345 la lettura dello stato di terminazione di un processo, analoghe alle
1346 precedenti ma che prevedono un ulteriore argomento attraverso il quale il
1347 kernel può restituire al padre informazioni sulle risorse (vedi
1348 sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
1349 Le due funzioni di sistema sono \funcd{wait3} e \funcd{wait4}, che diventano
1350 accessibili definendo la macro \macro{\_USE\_BSD}, i loro prototipi sono:
1355 \fhead{sys/resource.h}
1357 \fdecl{int wait3(int *status, int options, struct rusage *rusage)}
1358 \fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage)}
1359 \fdesc{Attende il cambiamento di stato di un processo figlio, riportando l'uso
1362 {La funzione ha gli stessi valori di ritorno e codici di errore di
1366 La funzione \func{wait4} è identica \func{waitpid} sia nel comportamento che
1367 per i valori dei primi tre argomenti, ma in più restituisce nell'argomento
1368 aggiuntivo \param{rusage} un sommario delle risorse usate dal processo. Questo
1369 argomento è una struttura di tipo \struct{rusage} definita in
1370 \headfile{sys/resource.h}, che viene utilizzata anche dalla funzione
1371 \func{getrusage} per ottenere le risorse di sistema usate da un processo. La
1372 sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct} e ne
1373 tratteremo in dettaglio il significato sez.~\ref{sec:sys_resource_use}. La
1374 funzione \func{wait3} è semplicemente un caso particolare di (e con Linux
1375 viene realizzata con la stessa \textit{system call}), ed è equivalente a
1376 chiamare \code{wait4(-1, \&status, opt, rusage)}, per questo motivo è ormai
1377 deprecata in favore di \func{wait4}.
1381 \subsection{La famiglia delle funzioni \func{exec} per l'esecuzione dei
1383 \label{sec:proc_exec}
1385 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1386 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1387 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1388 processo chiama una di queste funzioni esso viene completamente sostituito dal
1389 nuovo programma, il \ids{PID} del processo non cambia, dato che non viene
1390 creato un nuovo processo, la funzione semplicemente rimpiazza lo
1391 \textit{stack}, i dati ed il testo del processo corrente con un nuovo
1392 programma letto da disco, eseguendo il \textit{link-loader} con gli effetti
1393 illustrati in sez.~\ref{sec:proc_main}.
1395 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1396 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1397 (come mostrato in fig.~\ref{fig:proc_exec_relat}), tutte queste funzioni sono
1398 tutte varianti che consentono di invocare in modi diversi, semplificando il
1399 passaggio degli argomenti, la funzione di sistema \funcd{execve}, il cui
1404 \fdecl{int execve(const char *filename, char *const argv[], char *const envp[])}
1405 \fdesc{Esegue un programma.}
1407 {La funzione ritorna solo in caso di errore, restituendo $-1$, nel qual
1408 caso \var{errno} assumerà uno dei valori:
1410 \item[\errcode{EACCES}] il file o l'interprete non file ordinari, o non sono
1411 eseguibili, o il file è su un filesystem montato con l'opzione
1412 \cmd{noexec}, o manca il permesso di attraversamento di una delle
1413 directory del \textit{pathname}.
1414 \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
1415 \const{PT\_INTERP}, cioè chiede di essere eseguito da più di un
1417 \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
1419 \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
1420 riconosciuto come tale, o compilato per un'altra architettura.
1421 \item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1422 necessari per eseguirlo non esistono.
1423 \item[\errcode{EPERM}] il file ha i bit \acr{suid} o \acr{sgid} e l'utente
1424 non è root, ed il processo viene tracciato, oppure il filesystem è montato
1425 con l'opzione \cmd{nosuid}.
1426 \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
1428 \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
1430 ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{EISDIR}, \errval{ELOOP},
1431 \errval{EMFILE}, \errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOMEM},
1432 \errval{ENOTDIR} nel loro significato generico. }
1435 La funzione \func{execve} esegue il programma o lo script indicato dal
1436 \textit{pathname} \param{filename}, passandogli la lista di argomenti indicata
1437 da \param{argv} e come ambiente la lista di stringhe indicata
1438 da \param{envp}. Entrambe le liste devono essere terminate da un puntatore
1439 nullo. I vettori degli argomenti e dell'ambiente possono essere acceduti dal
1440 nuovo programma quando la sua funzione \code{main} è dichiarata nella forma
1441 \code{main(int argc, char *argv[], char *envp[])}. Si tenga presente per il
1442 passaggio degli argomenti e dell'ambiente esistono comunque dei limiti, su cui
1443 torneremo in sez.~\ref{sec:sys_res_limits}).
1444 % TODO aggiungere la parte sul numero massimo di argomenti, da man execve
1446 In caso di successo la funzione non ritorna, in quanto al posto del programma
1447 chiamante viene eseguito il nuovo programma indicato da \param{filename}. Se
1448 il processo corrente è tracciato con \func{ptrace} (vedi
1449 sez.~\ref{sec:process_ptrace}) in caso di successo viene emesso il segnale
1452 Le altre funzioni della famiglia (\funcd{execl}, \funcd{execv},
1453 \funcd{execle}, \funcd{execlp}, \funcd{execvp}) servono per fornire all'utente
1454 una serie di possibili diverse interfacce nelle modalità di passaggio degli
1455 argomenti all'esecuzione del nuovo programma. I loro prototipi sono:
1459 \fdecl{int execl(const char *path, const char *arg, ...)}
1460 \fdecl{int execv(const char *path, char *const argv[])}
1461 \fdecl{int execle(const char *path, const char *arg, ..., char * const envp[])}
1462 \fdecl{int execlp(const char *file, const char *arg, ...)}
1463 \fdecl{int execvp(const char *file, char *const argv[])}
1464 \fdesc{Eseguono un programma.}
1466 {Le funzioni ritornano solo in caso di errore, restituendo $-1$, i codici di
1467 errore sono gli stessi di \func{execve}.
1471 Tutte le funzioni mettono in esecuzione nel processo corrente il programma
1472 indicati nel primo argomento. Gli argomenti successivi consentono di
1473 specificare gli argomenti e l'ambiente che saranno ricevuti dal nuovo
1474 processo. Per capire meglio le differenze fra le funzioni della famiglia si può
1475 fare riferimento allo specchietto riportato in
1476 tab.~\ref{tab:proc_exec_scheme}. La relazione fra le funzioni è invece
1477 illustrata in fig.~\ref{fig:proc_exec_relat}.
1482 \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1484 \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
1485 \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1487 &\func{execl}\texttt{ }&\func{execlp}&\func{execle}
1488 &\func{execv}\texttt{ }& \func{execvp}& \func{execve} \\
1491 argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
1492 argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
1494 filename completo &$\bullet$&&$\bullet$&$\bullet$&&$\bullet$\\
1495 ricerca su \var{PATH} &&$\bullet$&&&$\bullet$& \\
1497 ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
1498 uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1501 \caption{Confronto delle caratteristiche delle varie funzioni della
1502 famiglia \func{exec}.}
1503 \label{tab:proc_exec_scheme}
1506 La prima differenza fra le funzioni riguarda le modalità di passaggio dei
1507 valori che poi andranno a costituire gli argomenti a linea di comando (cioè i
1508 valori di \param{argv} e \param{argc} visti dalla funzione \code{main} del
1509 programma chiamato). Queste modalità sono due e sono riassunte dagli mnemonici
1510 ``\texttt{v}'' e ``\texttt{l}'' che stanno rispettivamente per \textit{vector}
1513 Nel primo caso gli argomenti sono passati tramite il vettore di puntatori
1514 \var{argv[]} a stringhe terminate con zero che costituiranno gli argomenti a
1515 riga di comando, questo vettore \emph{deve} essere terminato da un puntatore
1516 nullo. Nel secondo caso le stringhe degli argomenti sono passate alla funzione
1517 come lista di puntatori, nella forma:
1518 \includecodesnip{listati/char_list.c}
1519 che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
1520 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1521 per indicare il nome del file che contiene il programma che verrà eseguito.
1523 \begin{figure}[!htb]
1524 \centering \includegraphics[width=9cm]{img/exec_rel}
1525 \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1526 \label{fig:proc_exec_relat}
1529 La seconda differenza fra le funzioni riguarda le modalità con cui si
1530 specifica il programma che si vuole eseguire. Con lo mnemonico ``\texttt{p}''
1531 si indicano le due funzioni che replicano il comportamento della shell nello
1532 specificare il comando da eseguire; quando l'argomento \param{file} non
1533 contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
1534 e viene eseguita automaticamente una ricerca fra i file presenti nella lista
1535 di directory specificate dalla variabile di ambiente \envvar{PATH}. Il file
1536 che viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1537 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1538 sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
1539 proseguita nelle eventuali ulteriori directory indicate in \envvar{PATH}; solo
1540 se non viene trovato nessun altro file viene finalmente restituito
1541 \errcode{EACCES}. Le altre quattro funzioni si limitano invece a cercare di
1542 eseguire il file indicato dall'argomento \param{path}, che viene interpretato
1543 come il \textit{pathname} del programma.
1545 La terza differenza è come viene passata la lista delle variabili di ambiente.
1546 Con lo mnemonico ``\texttt{e}'' vengono indicate quelle funzioni che
1547 necessitano di un vettore di parametri \var{envp[]} analogo a quello usato per
1548 gli argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
1549 usano il valore della variabile \var{environ} (vedi
1550 sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
1553 Oltre a mantenere lo stesso \ids{PID}, il nuovo programma fatto partire da una
1554 delle funzioni della famiglia \func{exec} mantiene la gran parte delle
1555 proprietà del processo chiamante; una lista delle più significative è la
1558 \item il \textit{process id} (\ids{PID}) ed il \textit{parent process id}
1560 \item l'\textsl{user-ID reale}, il \textsl{group-ID reale} ed i
1561 \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
1562 \item la directory radice (vedi sez.~\ref{sec:file_chroot}) e la directory di
1563 lavoro corrente (vedi sez.~\ref{sec:file_work_dir});
1564 \item la maschera di creazione dei file (\textit{umask}, vedi
1565 sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
1566 sez.~\ref{sec:file_locking});
1567 \item il valori di \textit{nice}, le priorità real-time e le affinità di
1568 processore (vedi sez.~\ref{sec:proc_sched_stand};
1569 sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
1570 \item il \textit{session ID} (\acr{sid}) ed il \textit{process group ID}
1571 (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
1572 \item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term});
1573 \item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
1574 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
1575 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime};
1576 \var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times});
1577 % TODO ===========Importante=============
1578 % TODO questo sotto è incerto, verificare
1579 % TODO ===========Importante=============
1580 \item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask}).
1583 Una serie di proprietà del processo originale, che non avrebbe senso mantenere
1584 in un programma che esegue un codice completamente diverso in uno spazio di
1585 indirizzi totalmente indipendente e ricreato da zero, vengono perse con
1586 l'esecuzione di una \func{exec}. Lo standard POSIX.1-2001 prevede che le
1587 seguenti proprietà non vengano preservate:
1589 \item l'insieme dei segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che
1591 \item gli eventuali stack alternativi per i segnali (vedi
1592 sez.~\ref{sec:sig_specific_features});
1593 \item i \textit{directory stream} (vedi sez.~\ref{sec:file_dir_read}), che
1595 \item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map});
1596 \item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm})
1597 e POSIX (vedi sez.~\ref{sec:ipc_posix_shm});
1598 \item i \textit{memory lock} (vedi sez.~\ref{sec:proc_mem_lock});
1599 \item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit});
1600 \item i semafori e le code di messaggi POSIX (vedi
1601 sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq});
1602 \item i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}).
1605 Inoltre i segnali che sono stati impostati per essere ignorati nel processo
1606 chiamante mantengono la stessa impostazione pure nel nuovo programma, ma tutti
1607 gli altri segnali, ed in particolare quelli per i quali è stato installato un
1608 gestore vengono impostati alla loro azione predefinita (vedi
1609 sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \signal{SIGCHLD}
1610 che, quando impostato a \const{SIG\_IGN}, potrebbe anche essere reimpostato a
1611 \const{SIG\_DFL}. Lo standard POSIX.1-2001 prevede che questo comportamento
1612 sia deciso dalla singola implementazione, quella di Linux è di non modificare
1613 l'impostazione precedente.
1615 Oltre alle precedenti, che sono completamente generali e disponibili anche su
1616 altri sistemi unix-like, esistono altre proprietà dei processi, attinenti alle
1617 caratteristiche specifiche di Linux, che non vengono preservate
1618 nell'esecuzione della funzione \func{exec}, queste sono:
1620 \item le operazioni di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io})
1621 pendenti vengono cancellate;
1622 \item le \textit{capabilities} vengono modificate come
1623 illustrato in sez.~\ref{sec:proc_capabilities};
1624 \item tutti i \textit{thread} tranne il chiamante (vedi
1625 sez.~\ref{sec:thread_xxx}) sono cancellati e tutti gli oggetti ad essi
1626 relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi;
1627 \item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi
1628 sez.~\ref{sec:process_prctl}) a meno che il programma da eseguire non sia
1629 \acr{suid} o \acr{sgid} (vedi sez.~\ref{sec:proc_access_id} e
1630 sez.~\ref{sec:file_special_perm});
1631 \item il flag \const{PR\_SET\_KEEPCAPS} di \func{prctl} (vedi
1632 sez.~\ref{sec:process_prctl}) viene cancellato;
1633 \item il nome del processo viene impostato al nome del file contenente il
1634 programma messo in esecuzione;
1635 \item il segnale di terminazione viene reimpostato a \signal{SIGCHLD};
1636 \item l'ambiente viene reinizializzato impostando le variabili attinenti alla
1637 localizzazione al valore di default POSIX.
1640 \itindbeg{close-on-exec}
1642 La gestione dei file aperti nel passaggio al nuovo programma lanciato con
1643 \func{exec} dipende dal valore che ha il flag di \textit{close-on-exec} (vedi
1644 sez.~\ref{sec:file_fcntl_ioctl}) per ciascun \textit{file descriptor}. I file
1645 per cui è impostato vengono chiusi, tutti gli altri file restano
1646 aperti. Questo significa che il comportamento predefinito è che i file restano
1647 aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
1648 \func{fcntl} che imposti il suddetto flag. Per le directory, lo standard
1649 POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere
1650 questo è fatto dalla funzione \func{opendir} (vedi
1651 sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
1652 \textit{close-on-exec} sulle directory che apre, in maniera trasparente
1655 \itindend{close-on-exec}
1657 Il comportamento della funzione in relazione agli identificatori relativi al
1658 controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
1659 qui è sufficiente anticipare (si faccia riferimento a
1660 sez.~\ref{sec:proc_access_id} per la definizione di questi identificatori)
1661 come l'\textsl{user-ID reale} ed il \textsl{group-ID reale} restano sempre gli
1662 stessi, mentre l'\textsl{user-ID salvato} ed il \textsl{group-ID salvato}
1663 vengono impostati rispettivamente all'\textsl{user-ID effettivo} ed il
1664 \textsl{group-ID effettivo}. Questi ultimi normalmente non vengono modificati,
1665 a meno che il file di cui viene chiesta l'esecuzione non abbia o il \acr{suid}
1666 bit o lo \acr{sgid} bit impostato (vedi sez.~\ref{sec:file_special_perm}), in
1667 questo caso l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo}
1668 vengono impostati rispettivamente all'utente o al gruppo cui il file
1671 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1672 condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
1673 del programma per caricare le librerie necessarie ed effettuare il link
1674 dell'eseguibile; il formato è ormai in completo disuso, per cui è molto
1675 probabile che non il relativo supporto non sia disponibile. Se il programma è
1676 in formato ELF per caricare le librerie dinamiche viene usato l'interprete
1677 indicato nel segmento \constd{PT\_INTERP} previsto dal formato stesso, in
1678 genere questo è \sysfiled{/lib/ld-linux.so.1} per programmi collegati con la
1679 \acr{libc5}, e \sysfiled{/lib/ld-linux.so.2} per programmi collegati con la
1682 Infine nel caso il programma che si vuole eseguire sia uno script e non un
1683 binario, questo deve essere un file di testo che deve iniziare con una linea
1686 #!/path/to/interpreter [argomenti]
1688 dove l'interprete indicato deve essere un eseguibile binario e non un altro
1689 script, che verrà chiamato come se si fosse eseguito il comando
1690 \cmd{interpreter [argomenti] filename}.
1692 Si tenga presente che con Linux quanto viene scritto come \texttt{argomenti}
1693 viene passato all'interprete come un unico argomento con una unica stringa di
1694 lunghezza massima di 127 caratteri e se questa dimensione viene ecceduta la
1695 stringa viene troncata; altri Unix hanno dimensioni massime diverse, e diversi
1696 comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide
1697 nei vari argomenti e se è troppo lunga restituisce un errore di
1698 \errval{ENAMETOOLONG}; una comparazione dei vari comportamenti sui diversi
1699 sistemi unix-like si trova su
1700 \url{http://www.in-ulm.de/~mascheck/various/shebang/}.
1702 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1703 basata la gestione tradizionale dei processi in Unix: con \func{fork} si crea
1704 un nuovo processo, con \func{exec} si lancia un nuovo programma, con
1705 \func{exit} e \func{wait} si effettua e verifica la conclusione dei
1706 processi. Tutte le altre funzioni sono ausiliarie e servono per la lettura e
1707 l'impostazione dei vari parametri connessi ai processi.
1711 \section{Il controllo di accesso}
1712 \label{sec:proc_perms}
1714 In questa sezione esamineremo le problematiche relative al controllo di
1715 accesso dal punto di vista dei processi; vedremo quali sono gli identificatori
1716 usati, come questi possono essere modificati nella creazione e nel lancio di
1717 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1718 problematiche connesse ad una gestione accorta dei privilegi.
1721 \subsection{Gli identificatori del controllo di accesso}
1722 \label{sec:proc_access_id}
1724 Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
1725 realtà già esistono estensioni di questo modello base, che lo rendono più
1726 flessibile e controllabile, come le \textit{capabilities} illustrate in
1727 sez.~\ref{sec:proc_capabilities}, le ACL per i file (vedi
1728 sez.~\ref{sec:file_ACL}) o il \textit{Mandatory Access Control} di
1729 \textit{SELinux}; inoltre basandosi sul lavoro effettuato con
1730 \textit{SELinux}, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
1731 infrastruttura di sicurezza, i \textit{Linux Security Modules}, o LSM, in
1732 grado di fornire diversi agganci a livello del kernel per modularizzare
1733 tutti i possibili controlli di accesso, cosa che ha permesso di realizzare
1734 diverse alternative a \textit{SELinux}.}
1735 di sicurezza di un sistema unix-like è fondato sui concetti di utente e
1736 gruppo, e sulla separazione fra l'amministratore (\textsl{root}, detto spesso
1737 anche \textit{superuser}) che non è sottoposto a restrizioni, ed il resto
1738 degli utenti, per i quali invece vengono effettuati i vari controlli di
1741 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1742 identificatori univoci, lo \itindex{User~ID~(UID)} \textsl{User-ID}
1743 (abbreviato in \ids{UID}) ed il \itindex{Group~ID~(GID)} \textsl{Group-ID}
1744 (abbreviato in \ids{GID}). Questi servono al kernel per identificare uno
1745 specifico utente o un gruppo di utenti, per poi poter controllare che essi
1746 siano autorizzati a compiere le operazioni richieste. Ad esempio in
1747 sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano associati
1748 un utente ed un gruppo (i suoi \textsl{proprietari}, indicati appunto tramite
1749 un \ids{UID} ed un \ids{GID}) che vengono controllati dal kernel nella
1750 gestione dei permessi di accesso.
1752 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1753 evidente che per poter implementare un controllo sulle operazioni occorre
1754 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1755 anche a ciascun processo dovrà essere associato un utente e un gruppo.
1757 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1758 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1759 disporre di privilegi diversi, o dover impersonare un altro utente per un
1760 limitato insieme di operazioni. Per questo motivo in generale tutti i sistemi
1761 unix-like prevedono che i processi abbiano almeno due gruppi di
1762 identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}
1763 (cioè \textsl{reali} ed \textsl{effettivi}). Nel caso di Linux si aggiungono
1764 poi altri due gruppi, il \textit{saved} (\textsl{salvati}) ed il
1765 \textit{filesystem} (\textsl{di filesystem}), secondo la situazione illustrata
1766 in tab.~\ref{tab:proc_uid_gid}.
1771 \begin{tabular}[c]{|c|c|l|p{7cm}|}
1773 \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
1774 & \textbf{Significato} \\
1777 \texttt{uid} & \textit{real} & \textsl{user-ID reale}
1778 & Indica l'utente che ha lanciato il programma.\\
1779 \texttt{gid} & '' &\textsl{group-ID reale}
1780 & Indica il gruppo principale dell'utente che ha lanciato
1783 \texttt{euid}& \textit{effective} &\textsl{user-ID effettivo}
1784 & Indica l'utente usato nel controllo di accesso.\\
1785 \texttt{egid}& '' & \textsl{group-ID effettivo}
1786 & Indica il gruppo usato nel controllo di accesso.\\
1787 -- & -- & \textsl{group-ID supplementari}
1788 & Indicano gli ulteriori gruppi cui l'utente appartiene.\\
1790 -- & \textit{saved} & \textsl{user-ID salvato}
1791 & Mantiene una copia dell'\acr{euid} iniziale.\\
1792 -- & '' & \textsl{group-ID salvato}
1793 & Mantiene una copia dell'\acr{egid} iniziale.\\
1795 \texttt{fsuid}& \textit{filesystem} &\textsl{user-ID di filesystem}
1796 & Indica l'utente effettivo per l'accesso al filesystem. \\
1797 \texttt{fsgid}& '' & \textsl{group-ID di filesystem}
1798 & Indica il gruppo effettivo per l'accesso al filesystem.\\
1801 \caption{Identificatori di utente e gruppo associati a ciascun processo con
1802 indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
1803 \label{tab:proc_uid_gid}
1806 Al primo gruppo appartengono l'\ids{UID} \textsl{reale} ed il \ids{GID}
1807 \textsl{reale}: questi vengono impostati al login ai valori corrispondenti
1808 all'utente con cui si accede al sistema (e relativo gruppo principale).
1809 Servono per l'identificazione dell'utente e normalmente non vengono mai
1810 cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
1811 modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
1812 questa possibilità è usata proprio dal programma \cmd{login} che, una volta
1813 completata la procedura di autenticazione, lancia una shell per la quale
1814 imposta questi identificatori ai valori corrispondenti all'utente che entra
1817 Al secondo gruppo appartengono l'\ids{UID} \textsl{effettivo} e il \ids{GID}
1818 \textsl{effettivo}, a cui si aggiungono gli eventuali \ids{GID}
1819 \textsl{supplementari} dei gruppi dei quali l'utente fa parte. Questi sono
1820 invece gli identificatori usati nelle verifiche dei permessi del processo e
1821 per il controllo di accesso ai file (argomento affrontato in dettaglio in
1822 sez.~\ref{sec:file_perm_overview}).
1824 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1825 \textit{real} tranne nel caso in cui, come accennato in
1826 sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
1827 bit \acr{suid} o \acr{sgid} impostati (il significato di questi bit è
1828 affrontato in dettaglio in sez.~\ref{sec:file_special_perm}). In questo caso
1829 essi saranno impostati all'utente e al gruppo proprietari del file. Questo
1830 consente, per programmi in cui ci sia questa necessità, di dare a qualunque
1831 utente i privilegi o i permessi di un altro, compreso l'amministratore.
1833 Come nel caso del \ids{PID} e del \ids{PPID}, anche tutti questi
1834 identificatori possono essere ottenuti da un programma attraverso altrettante
1835 funzioni di sistema dedicate alla loro lettura, queste sono \funcd{getuid},
1836 \funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, ed i loro prototipi sono:
1841 \fdecl{uid\_t getuid(void)}
1842 \fdesc{Legge l'\ids{UID} reale del processo corrente.}
1843 \fdecl{uid\_t geteuid(void)}
1844 \fdesc{Legge l'\ids{UID} effettivo del processo corrente.}
1845 \fdecl{gid\_t getgid(void)}
1846 \fdesc{Legge il \ids{GID} reale del processo corrente.}
1847 \fdecl{gid\_t getegid(void)}
1848 \fdesc{Legge il \ids{GID} effettivo del processo corrente.}
1850 {Le funzioni ritornano i rispettivi identificativi del processo corrente, e
1851 non sono previste condizioni di errore.}
1854 In generale l'uso di privilegi superiori, ottenibile con un \ids{UID}
1855 \textsl{effettivo} diverso da quello reale, deve essere limitato il più
1856 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1857 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1858 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1859 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1862 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
1863 \textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
1864 SVr4, e previsto dallo standard POSIX quando è definita
1865 \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
1866 del programma su altri Unix è buona norma controllare sempre la
1867 disponibilità di queste funzioni controllando se questa costante è
1868 definita.} il secondo gruppo è specifico di Linux e viene usato per
1869 migliorare la sicurezza con NFS (il \textit{Network File System}, protocollo
1870 che consente di accedere ai file via rete).
1872 L'\ids{UID} \textsl{salvato} ed il \ids{GID} \textsl{salvato} sono copie
1873 dell'\ids{UID} \textsl{effettivo} e del \ids{GID} \textsl{effettivo} del
1874 processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del
1875 processo, come copie dell'\ids{UID} \textsl{effettivo} e del \ids{GID}
1876 \textsl{effettivo} dopo che questi sono stati impostati tenendo conto di
1877 eventuali permessi \acr{suid} o \acr{sgid} (su cui torneremo in
1878 sez.~\ref{sec:file_special_perm}). Essi quindi consentono di tenere traccia
1879 di quale fossero utente e gruppo effettivi all'inizio dell'esecuzione di un
1882 L'\ids{UID} \textsl{di filesystem} e il \ids{GID} \textsl{di filesystem} sono
1883 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
1884 (torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una
1885 replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
1886 quali si sostituiscono per tutte le operazioni di verifica dei permessi
1887 relativi ai file (trattate in sez.~\ref{sec:file_perm_overview}). Ogni
1888 cambiamento effettuato sugli identificatori effettivi viene automaticamente
1889 riportato su di essi, per cui in condizioni normali si può tranquillamente
1890 ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
1893 \subsection{Le funzioni di gestione degli identificatori dei processi}
1894 \label{sec:proc_setuid}
1896 Le funzioni di sistema più comuni che vengono usate per cambiare identità
1897 (cioè utente e gruppo di appartenenza) ad un processo, e che come accennato in
1898 sez.~\ref{sec:proc_access_id} seguono la semantica POSIX che prevede
1899 l'esistenza dell'\ids{UID} salvato e del \ids{GID} salvato, sono
1900 rispettivamente \funcd{setuid} e \funcd{setgid}; i loro prototipi sono:
1905 \fdecl{int setuid(uid\_t uid)}
1906 \fdesc{Imposta l'\ids{UID} del processo corrente.}
1907 \fdecl{int setgid(gid\_t gid)}
1908 \fdesc{Imposta il \ids{GID} del processo corrente.}
1910 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
1911 caso \var{errno} può assumere solo il valore \errcode{EPERM}.
1915 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1916 la prima, la seconda si comporta esattamente allo stesso modo facendo
1917 riferimento al \ids{GID} invece che all'\ids{UID}. Gli eventuali \ids{GID}
1918 supplementari non vengono modificati.
1920 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1921 l'\ids{UID} effettivo è zero (cioè è quello dell'amministratore di sistema)
1922 allora tutti gli identificatori (\textit{real}, \textit{effective} e
1923 \textit{saved}) vengono impostati al valore specificato da \param{uid},
1924 altrimenti viene impostato solo l'\ids{UID} effettivo, e soltanto se il valore
1925 specificato corrisponde o all'\ids{UID} reale o all'\ids{UID} salvato. Negli
1926 altri casi viene segnalato un errore con \errcode{EPERM}.
1928 Come accennato l'uso principale di queste funzioni è quello di poter
1929 consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati (vedi
1930 sez.~\ref{sec:file_special_perm}) di riportare l'\ids{UID} effettivo a quello
1931 dell'utente che ha lanciato il programma, effettuare il lavoro che non
1932 necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
1934 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1935 viene gestito l'accesso al file \sysfiled{/var/run/utmp}. In questo file viene
1936 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1937 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1938 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1939 \sysfiled{/var/log/wtmp} su cui vengono registrati login e logout) appartengono
1940 ad un gruppo dedicato (in genere \acr{utmp}) ed i programmi che devono
1941 accedervi (ad esempio tutti i programmi di terminale in X, o il programma
1942 \cmd{screen} che crea terminali multipli su una console) appartengono a questo
1943 gruppo ed hanno il bit \acr{sgid} impostato.
1945 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1946 situazione degli identificatori è la seguente:
1949 \textsl{group-ID reale} &=& \textrm{\ids{GID} (del chiamante)} \\
1950 \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
1951 \textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
1953 in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
1954 programma può accedere a \sysfile{/var/run/utmp} in scrittura ed aggiornarlo.
1955 A questo punto il programma può eseguire una \code{setgid(getgid())} per
1956 impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
1957 \textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
1958 non sarà possibile lanciare dal terminale programmi che modificano detto file,
1959 in tal caso infatti la situazione degli identificatori sarebbe:
1962 \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
1963 \textsl{group-ID effettivo} &=& \textrm{\ids{GID}} \\
1964 \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
1966 e ogni processo lanciato dal terminale avrebbe comunque \ids{GID} come
1967 \textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
1968 aggiornare lo stato di \sysfile{/var/run/utmp} il programma eseguirà una
1969 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1970 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
1971 in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
1972 funzione avrà successo e riporterà la situazione a:
1975 \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
1976 \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
1977 \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
1979 consentendo l'accesso a \sysfile{/var/run/utmp}.
1981 Occorre però tenere conto che tutto questo non è possibile con un processo con
1982 i privilegi di amministratore, in tal caso infatti l'esecuzione di una
1983 \func{setuid} comporta il cambiamento di tutti gli identificatori associati al
1984 processo, rendendo impossibile riguadagnare i privilegi di amministratore.
1985 Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
1986 crea una nuova shell per l'utente, ma quando si vuole cambiare soltanto
1987 l'\ids{UID} effettivo del processo per cedere i privilegi occorre
1988 ricorrere ad altre funzioni.
1990 Le due funzioni di sistema \funcd{setreuid} e \funcd{setregid} derivano da BSD
1991 che, non supportando (almeno fino alla versione 4.3+BSD) gli identificatori
1992 del gruppo \textit{saved}, le usa per poter scambiare fra di loro
1993 \textit{effective} e \textit{real}; i rispettivi prototipi sono:
1998 \fdecl{int setreuid(uid\_t ruid, uid\_t euid)}
1999 \fdesc{Imposta \ids{UID} reale e \ids{UID} effettivo del processo corrente.}
2000 \fdecl{int setregid(gid\_t rgid, gid\_t egid)}
2001 \fdesc{Imposta \ids{GID} reale e \ids{GID} effettivo del processo corrente.}
2003 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2004 caso \var{errno} può assumere solo il valore \errcode{EPERM}.
2008 Le due funzioni sono identiche, quanto diremo per la prima riguardo gli
2009 \ids{UID} si applica alla seconda per i \ids{GID}. La funzione
2010 \func{setreuid} imposta rispettivamente l'\ids{UID} reale e l'\ids{UID}
2011 effettivo del processo corrente ai valori specificati da \param{ruid}
2012 e \param{euid}. I processi non privilegiati possono impostare solo valori che
2013 corrispondano o al loro \ids{UID} effettivo o a quello reale o a quello
2014 salvato, valori diversi comportano il fallimento della chiamata.
2015 L'amministratore invece può specificare un valore qualunque. Specificando un
2016 argomento di valore $-1$ l'identificatore corrispondente verrà lasciato
2019 Con queste funzioni si possono scambiare fra loro gli \ids{UID} reale ed
2020 effettivo, e pertanto è possibile implementare un comportamento simile a
2021 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
2022 scambio, e recuperandoli, una volta eseguito il lavoro non privilegiato, con
2025 In questo caso però occorre porre molta attenzione quando si creano nuovi
2026 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
2027 questo caso infatti essi avranno un \ids{UID} reale privilegiato, che dovrà
2028 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
2029 programma, occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
2030 prima della \func{exec} per uniformare l'\ids{UID} reale a quello effettivo,
2031 perché in caso contrario il nuovo programma potrebbe a sua volta effettuare
2032 uno scambio e riottenere dei privilegi non previsti.
2034 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
2035 si pone anche per l'\ids{UID} salvato. Ma la funzione \func{setreuid} deriva
2036 da un'implementazione di sistema che non ne prevede la presenza, e quindi non
2037 è possibile usarla per correggere la situazione come nel caso precedente. Per
2038 questo motivo in Linux tutte le volte che si imposta un qualunque valore
2039 diverso da quello dall'\ids{UID} reale corrente, l'\ids{UID} salvato viene
2040 automaticamente uniformato al valore dell'\ids{UID} effettivo.
2042 Altre due funzioni di sistema, \funcd{seteuid} e \funcd{setegid}, sono
2043 un'estensione dello standard POSIX.1, ma sono comunque supportate dalla
2044 maggior parte degli Unix, esse vengono usate per cambiare gli identificatori
2045 del gruppo \textit{effective} ed i loro prototipi sono:
2050 \fdecl{int seteuid(uid\_t uid)}
2051 \fdesc{Imposta l'\ids{UID} effettivo del processo corrente.}
2052 \fdecl{int setegid(gid\_t gid)}
2053 \fdesc{Imposta il \ids{GID} effettivo del processo corrente.}
2055 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2056 caso \var{errno} può assumere solo il valore \errcode{EPERM}.
2060 Ancora una volta le due funzioni sono identiche, e quanto diremo per la prima
2061 riguardo gli \ids{UID} si applica allo stesso modo alla seconda per i
2062 \ids{GID}. Con \func{seteuid} gli utenti normali possono impostare l'\ids{UID}
2063 effettivo solo al valore dell'\ids{UID} reale o dell'\ids{UID} salvato,
2064 l'amministratore può specificare qualunque valore. Queste funzioni sono usate
2065 per permettere all'amministratore di impostare solo l'\ids{UID} effettivo,
2066 dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli
2069 Le due funzioni di sistema \funcd{setresuid} e \funcd{setresgid} sono invece
2070 un'estensione introdotta in Linux (a partire dal kernel 2.1.44) e permettono
2071 un completo controllo su tutti e tre i gruppi di identificatori
2072 (\textit{real}, \textit{effective} e \textit{saved}), i loro prototipi sono:
2077 \fdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)}
2078 \fdesc{Imposta l'\ids{UID} reale, effettivo e salvato del processo corrente.}
2079 \fdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)}
2080 \fdesc{Imposta il \ids{GID} reale, effettivo e salvato del processo corrente.}
2082 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2083 caso \var{errno} può assumere solo il valore \errcode{EPERM}.
2087 Di nuovo le due funzioni sono identiche e quanto detto per la prima riguardo
2088 gli \ids{UID} si applica alla seconda per i \ids{GID}. La funzione
2089 \func{setresuid} imposta l'\ids{UID} reale, l'\ids{UID} effettivo e
2090 l'\ids{UID} salvato del processo corrente ai valori specificati
2091 rispettivamente dagli argomenti \param{ruid}, \param{euid} e \param{suid}. I
2092 processi non privilegiati possono cambiare uno qualunque degli\ids{UID} solo
2093 ad un valore corrispondente o all'\ids{UID} reale, o a quello effettivo o a
2094 quello salvato, l'amministratore può specificare i valori che vuole. Un valore
2095 di $-1$ per un qualunque argomento lascia inalterato l'identificatore
2098 Per queste funzioni di sistema esistono anche due controparti,
2099 \funcd{getresuid} e \funcd{getresgid},\footnote{le funzioni non sono standard,
2100 anche se appaiono in altri kernel, su Linux sono presenti dal kernel 2.1.44
2101 e con le versioni della \acr{glibc} a partire dalla 2.3.2, definendo la
2102 macro \macro{\_GNU\_SOURCE}.} che permettono di leggere in blocco i vari
2103 identificatori; i loro prototipi sono:
2108 \fdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)}
2109 \fdesc{Legge l'\ids{UID} reale, effettivo e salvato del processo corrente.}
2110 \fdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)}
2111 \fdesc{Legge il \ids{GID} reale, effettivo e salvato del processo corrente.}
2113 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2114 caso \var{errno} può assumere solo il valore \errcode{EFAULT} se gli
2115 indirizzi delle variabili di ritorno non sono validi. }
2118 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
2119 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
2120 specificati come puntatori (è un altro esempio di \textit{value result
2121 argument}). Si noti che queste funzioni sono le uniche in grado di leggere
2122 gli identificatori del gruppo \textit{saved}.
2124 Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
2125 identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
2126 controllo dell'accesso ai file. Come già accennato in
2127 sez.~\ref{sec:proc_access_id} Linux definisce questo ulteriore gruppo di
2128 identificatori, che in circostanze normali sono assolutamente equivalenti a
2129 quelli del gruppo \textit{effective}, dato che ogni cambiamento di questi
2130 ultimi viene immediatamente riportato su di essi.
2132 C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
2133 identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
2134 ovviare ad un problema di sicurezza che si presenta quando si deve
2135 implementare un server NFS.
2137 Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
2138 file per assumere l'identità del singolo utente remoto, ma se questo viene
2139 fatto cambiando l'\ids{UID} effettivo o l'\ids{UID} reale il server si espone
2140 alla ricezione di eventuali segnali ostili da parte dell'utente di cui ha
2141 temporaneamente assunto l'identità. Cambiando solo l'\ids{UID} di filesystem
2142 si ottengono i privilegi necessari per accedere ai file, mantenendo quelli
2143 originari per quanto riguarda tutti gli altri controlli di accesso, così che
2144 l'utente non possa inviare segnali al server NFS.
2146 Le due funzioni di sistema usate appositamente per cambiare questi
2147 identificatori sono \funcd{setfsuid} e \funcd{setfsgid} ovviamente sono
2148 specifiche di Linux e non devono essere usate se si intendono scrivere
2149 programmi portabili; i loro prototipi sono:
2153 \fdecl{int setfsuid(uid\_t fsuid)}
2154 \fdesc{Imposta l'\ids{UID} di filesystem del processo corrente.}
2155 \fdecl{int setfsgid(gid\_t fsgid)}
2156 \fdesc{Legge il \ids{GID} di filesystem del processo corrente.}
2158 {Le funzioni restituiscono il nuovo valore dell'identificativo in caso di
2159 successo e quello corrente per un errore, in questo caso non viene però
2160 impostato nessun codice di errore in \var{errno}.}
2163 Le due funzioni sono analoghe ed usano il valore passato come argomento per
2164 effettuare l'impostazione dell'identificativo. Le funzioni hanno successo
2165 solo se il processo chiamante ha i privilegi di amministratore o, per gli
2166 altri utenti, se il valore specificato coincide con uno dei di quelli del
2167 gruppo \textit{real}, \textit{effective} o \textit{saved}.
2170 \subsection{Le funzioni per la gestione dei gruppi associati a un processo}
2171 \label{sec:proc_setgroups}
2173 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
2174 gruppi supplementari cui un utente può appartenere. Ogni processo può avere
2175 almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
2176 gruppi secondari può essere ottenuto con \func{sysconf} (vedi
2177 sez.~\ref{sec:sys_limits}), leggendo il parametro
2178 \const{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
2179 ereditati dal processo padre e possono essere cambiati con queste funzioni.
2181 La funzione di sistema che permette di leggere i gruppi supplementari
2182 associati ad un processo è \funcd{getgroups}; questa funzione è definita nello
2183 standard POSIX.1, ed il suo prototipo è:
2188 \fdecl{int getgroups(int size, gid\_t list[])}
2189 \fdesc{Legge gli identificatori dei gruppi supplementari.}
2191 {La funzione ritorna il numero di gruppi letti in caso di successo e $-1$ per
2192 un errore, nel qual caso \var{errno} assumerà uno dei valori:
2194 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
2195 \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
2196 minore del numero di gruppi supplementari del processo.
2200 La funzione legge gli identificatori dei gruppi supplementari del processo sul
2201 vettore \param{list} che deve essere di dimensione pari a \param{size}. Non è
2202 specificato se la funzione inserisca o meno nella lista il \ids{GID} effettivo
2203 del processo. Se si specifica un valore di \param{size} uguale a $0$ allora
2204 l'argomento \param{list} non viene modificato, ma si ottiene il numero di
2205 gruppi supplementari.
2207 Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
2208 ottenere tutti i gruppi a cui appartiene utente identificato per nome; il suo
2213 \fdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups, int
2215 \fdesc{Legge i gruppi cui appartiene un utente.}
2217 {La funzione ritorna il numero di gruppi ottenuto in caso di successo e $-1$
2218 per un errore, che avviene solo quando il numero di gruppi è maggiore di
2219 quelli specificati con \param{ngroups}.}
2222 La funzione esegue una scansione del database dei gruppi (si veda
2223 sez.~\ref{sec:sys_user_group}) per leggere i gruppi supplementari dell'utente
2224 specificato per nome (e non con un \ids{UID}) nella stringa passata con
2225 l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei
2226 \ids{GID} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
2227 che in ingresso deve indicare la dimensione di \param{group}, è passato come
2228 \textit{value result argument} perché, qualora il valore specificato sia
2229 troppo piccolo, la funzione ritorna $-1$, passando comunque indietro il numero
2230 dei gruppi trovati, in modo da poter ripetere la chiamata con un vettore di
2231 dimensioni adeguate.
2233 Infine per impostare i gruppi supplementari di un processo ci sono due
2234 funzioni, che possono essere usate solo se si hanno i privilegi di
2235 amministratore.\footnote{e più precisamente se si ha la \textit{capability}
2236 \const{CAP\_SETGID}.} La prima delle due è la funzione di sistema
2237 \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a
2238 differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
2239 poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed
2244 \fdecl{int setgroups(size\_t size, gid\_t *list)}
2245 \fdesc{Imposta i gruppi supplementari del processo.}
2247 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2248 caso \var{errno} assumerà uno dei valori:
2250 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
2251 \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
2252 massimo consentito di gruppi supplementari.
2253 \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
2257 La funzione imposta i gruppi supplementari del processo corrente ai valori
2258 specificati nel vettore passato con l'argomento \param{list}, di dimensioni
2259 date dall'argomento \param{size}. Il numero massimo di gruppi supplementari
2260 che si possono impostare è un parametro di sistema, che può essere ricavato
2261 con le modalità spiegate in sez.~\ref{sec:sys_characteristics}.
2263 Se invece si vogliono impostare i gruppi supplementari del processo a quelli
2264 di un utente specifico, si può usare la funzione \funcd{initgroups} il cui
2270 \fdecl{int initgroups(const char *user, gid\_t group)}
2271 \fdesc{Inizializza la lista dei gruppi supplementari.}
2273 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2274 caso \var{errno} assumerà uno dei valori:
2276 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare lo spazio per
2277 informazioni dei gruppi.
2278 \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
2282 La funzione esegue la scansione del database dei gruppi (usualmente
2283 \conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
2284 (di nuovo specificato per nome e non per \ids{UID}) con cui costruisce una
2285 lista di gruppi supplementari, a cui aggiunge anche \param{group}, infine
2286 imposta questa lista per il processo corrente usando \func{setgroups}. Si
2287 tenga presente che sia \func{setgroups} che \func{initgroups} non sono
2288 definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
2289 quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
2290 \cmd{-ansi}, è pertanto meglio evitarle se si vuole scrivere codice portabile.
2293 \section{La gestione della priorità dei processi}
2294 \label{sec:proc_priority}
2296 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
2297 lo \textit{scheduler} assegna la CPU ai vari processi attivi. In particolare
2298 prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del
2299 tempo di CPU, ed illustreremo le varie funzioni di gestione. Tratteremo infine
2300 anche le altre priorità dei processi (come quelle per l'accesso a disco)
2301 divenute disponibili con i kernel più recenti.
2304 \subsection{I meccanismi di \textit{scheduling}}
2305 \label{sec:proc_sched}
2307 \itindbeg{scheduler}
2309 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
2310 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
2311 ed oggetto di numerose ricerche; in generale essa dipende in maniera
2312 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
2313 cui non esiste un meccanismo che sia valido per tutti gli usi.
2315 La caratteristica specifica di un sistema multitasking come Linux è quella del
2316 cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
2317 multitasking}: questo significa che al contrario di altri sistemi (che usano
2318 invece il cosiddetto \itindex{cooperative~multitasking} \textit{cooperative
2319 multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
2320 quando la CPU deve essere passata ad un altro processo. Come accennato in
2321 sez.~\ref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
2322 apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
2323 distribuire al meglio il tempo di CPU fra i vari processi.
2325 La cosa è resa ancora più complicata dal fatto che con le architetture
2326 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
2327 utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
2328 rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
2329 un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
2330 banale.} Tutto questo comunque appartiene alle sottigliezze
2331 dell'implementazione del kernel; dal punto di vista dei programmi che girano
2332 in \textit{user space}, anche quando si hanno più processori (e dei processi
2333 che sono eseguiti davvero in contemporanea), le politiche di
2334 \textit{scheduling} riguardano semplicemente l'allocazione della risorsa
2335 \textsl{tempo di esecuzione}, la cui assegnazione sarà governata dai
2336 meccanismi di scelta delle priorità che restano gli stessi indipendentemente
2337 dal numero di processori.
2339 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
2340 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
2341 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
2342 tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
2343 kernel provvedere a mettere in esecuzione un altro processo.
2345 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
2346 processo, in Linux un processo può trovarsi in uno degli stati riportati in
2347 tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
2348 \textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
2349 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
2350 fintanto che esso si trova in uno qualunque degli altri stati.
2355 \begin{tabular}[c]{|p{2.4cm}|c|p{9cm}|}
2357 \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
2360 \textit{runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
2361 essere eseguito (cioè è in attesa che gli
2362 venga assegnata la CPU).\\
2363 \textit{sleep} & \texttt{S} & Il processo è in attesa di un
2364 risposta dal sistema, ma può essere
2365 interrotto da un segnale.\\
2366 \textit{uninterrutible sleep}& \texttt{D} & Il processo è in
2367 attesa di un risposta dal sistema (in
2368 genere per I/O), e non può essere
2369 interrotto in nessuna circostanza.\\
2370 \textit{stopped} & \texttt{T} & Il processo è stato fermato con un
2371 \signal{SIGSTOP}, o è tracciato.\\
2372 \textit{zombie} & \texttt{Z} & Il processo è terminato ma il
2373 suo stato di terminazione non è ancora
2374 stato letto dal padre.\\
2375 \textit{killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
2376 2.6.25, sostanzialmente identico
2377 all'\textit{uninterrutible sleep} con la
2378 sola differenza che il processo può
2379 terminato con \signal{SIGKILL} (usato per
2383 \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
2384 \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
2385 \cmd{ps} nell'omonimo campo.}
2386 \label{tab:proc_proc_states}
2389 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
2390 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
2391 dello scopo del programma non è detto neanche che sia la più importante, dato
2392 che molti programmi dipendono in maniera molto più critica dall'I/O. Per
2393 questo motivo non è affatto detto che dare ad un programma la massima priorità
2394 di esecuzione abbia risultati significativi in termini di prestazioni.
2396 Il meccanismo tradizionale di \textit{scheduling} di Unix (che tratteremo in
2397 sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
2398 \textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
2399 i meno importanti, potessero ricevere un po' di tempo di CPU. In sostanza
2400 quando un processo ottiene la CPU la sua priorità viene diminuita. In questo
2401 modo alla fine, anche un processo con priorità iniziale molto bassa, finisce
2402 per avere una priorità sufficiente per essere eseguito.
2404 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
2405 assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
2406 alla normale priorità dinamica), per tenere conto dei sistemi
2407 \textit{real-time},\footnote{per sistema \textit{real-time} si intende un
2408 sistema in grado di eseguire operazioni in un tempo ben determinato; in
2409 genere si tende a distinguere fra l'\textit{hard real-time} in cui è
2410 necessario che i tempi di esecuzione di un programma siano determinabili con
2411 certezza assoluta (come nel caso di meccanismi di controllo di macchine,
2412 dove uno sforamento dei tempi avrebbe conseguenze disastrose), e
2413 \textit{soft-real-time} in cui un occasionale sforamento è ritenuto
2414 accettabile.} in cui è vitale che i processi che devono essere eseguiti in
2415 un determinato momento non debbano aspettare la conclusione di altri che non
2416 hanno questa necessità.
2418 Il concetto di priorità assoluta dice che quando due processi si contendono
2419 l'esecuzione, vince sempre quello con la priorità assoluta più alta.
2420 Ovviamente questo avviene solo per i processi che sono pronti per essere
2421 eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
2422 genere indicata con un numero intero, ed un valore più alto comporta una
2423 priorità maggiore. Su questa politica di \textit{scheduling} torneremo in
2424 sez.~\ref{sec:proc_real_time}.
2426 In generale quello che succede in tutti gli Unix moderni è che ai processi
2427 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
2428 assegnazione della CPU è fatta solo con il meccanismo tradizionale della
2429 priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
2430 assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
2431 priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
2435 \subsection{Il meccanismo di \textit{scheduling} standard}
2436 \label{sec:proc_sched_stand}
2438 A meno che non si abbiano esigenze specifiche,\footnote{per alcune delle quali
2439 sono state introdotte delle varianti specifiche.} l'unico meccanismo di
2440 \textit{scheduling} con il quale si avrà a che fare è quello tradizionale, che
2441 prevede solo priorità dinamiche. È di questo che, di norma, ci si dovrà
2442 preoccupare nella programmazione. Come accennato in Linux i processi ordinari
2443 hanno tutti una priorità assoluta nulla; quello che determina quale, fra tutti
2444 i processi in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
2445 \textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
2446 \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
2447 varia nel corso dell'esecuzione di un processo.
2449 Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
2450 dipende strettamente dalla versione di kernel; in particolare a partire
2451 dalla serie 2.6.x lo \textit{scheduler} è stato riscritto completamente, con
2452 molte modifiche susseguitesi per migliorarne le prestazioni, per un certo
2453 periodo ed è stata anche introdotta la possibilità di usare diversi
2454 algoritmi, selezionabili sia in fase di compilazione, che, nelle versioni
2455 più recenti, all'avvio (addirittura è stato ideato un sistema modulare che
2456 permette di cambiare lo \textit{scheduler} a sistema attivo).} ma a grandi
2457 linee si può dire che ad ogni processo è assegnata una \textit{time-slice},
2458 cioè un intervallo di tempo (letteralmente una fetta) per il quale, a meno di
2459 eventi esterni, esso viene eseguito senza essere interrotto. Inoltre la
2460 priorità dinamica viene calcolata dallo \textit{scheduler} a partire da un
2461 valore iniziale che viene \textsl{diminuito} tutte le volte che un processo è
2462 in stato \textit{runnable} ma non viene posto in esecuzione.\footnote{in
2463 realtà il calcolo della priorità dinamica e la conseguente scelta di quale
2464 processo mettere in esecuzione avviene con un algoritmo molto più
2465 complicato, che tiene conto anche della \textsl{interattività} del processo,
2466 utilizzando diversi fattori, questa è una brutale semplificazione per
2467 rendere l'idea del funzionamento, per una trattazione più dettagliata, anche
2468 se non aggiornatissima, dei meccanismi di funzionamento dello
2469 \textit{scheduler} si legga il quarto capitolo di \cite{LinKernDev}.} Lo
2470 \textit{scheduler} infatti mette sempre in esecuzione, fra tutti i processi in
2471 stato \textit{runnable}, quello che ha il valore di priorità dinamica più
2472 basso.\footnote{con le priorità dinamiche il significato del valore numerico
2473 ad esse associato è infatti invertito, un valore più basso significa una
2474 priorità maggiore.} Il fatto che questo valore venga diminuito quando un
2475 processo non viene posto in esecuzione pur essendo pronto, significa che la
2476 priorità dei processi che non ottengono l'uso del processore viene
2477 progressivamente incrementata, così che anche questi alla fine hanno la
2478 possibilità di essere eseguiti.
2480 Sia la dimensione della \textit{time-slice} che il valore di partenza della
2481 priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
2482 \textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
2483 che ciascun processo si porta dietro, essa viene ereditata dai processi
2484 figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era
2485 mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con
2486 la riscrittura dello \textit{scheduler} eseguita nel 2.6 viene mantenuta nel
2487 campo \texttt{static\_prio} come per le priorità statiche.} L'origine del
2488 nome di questo parametro sta nel fatto che generalmente questo viene usato per
2489 \textsl{diminuire} la priorità di un processo, come misura di cortesia nei
2490 confronti degli altri. I processi infatti vengono creati dal sistema con un
2491 valore nullo e nessuno è privilegiato rispetto agli altri. Specificando un
2492 valore di \textit{nice} positivo si avrà una \textit{time-slice} più breve ed
2493 un valore di priorità dinamica iniziale più alto, mentre un valore negativo
2494 darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
2497 Esistono diverse funzioni che consentono di indicare un valore di
2498 \textit{nice} di un processo; la più semplice è \funcd{nice}, che opera sul
2499 processo corrente, il suo prototipo è:
2503 \fdecl{int nice(int inc)}
2504 \fdesc{Aumenta il valore di \textit{nice} del processo corrente.}
2506 {La funzione ritorna il nuovo valore di \textit{nice} in caso di successo e
2507 $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
2509 \item[\errcode{EPERM}] non si ha il permesso di specificare un valore
2510 di \param{inc} negativo.
2514 \constbeg{PRIO\_MIN}
2515 \constbeg{PRIO\_MAX}
2517 L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore
2518 di \textit{nice} corrente, che può assumere valori compresi fra
2519 \const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e
2520 $19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
2521 kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
2522 anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
2523 un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
2524 il risultato nell'intervallo consentito. Valori positivi comportano maggiore
2525 \textit{cortesia} e cioè una diminuzione della priorità, valori negativi
2526 comportano invece un aumento della priorità. Con i kernel precedenti il 2.6.12
2527 solo l'amministratore\footnote{o un processo con la \textit{capability}
2528 \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} può
2529 specificare valori negativi di \param{inc} che permettono di aumentare la
2530 priorità di un processo, a partire da questa versione è consentito anche agli
2531 utenti normali alzare (entro certi limiti, che vedremo in
2532 sez.~\ref{sec:sys_resource_limit}) la priorità dei propri processi.
2534 \constend{PRIO\_MIN}
2535 \constend{PRIO\_MAX}
2537 Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
2538 di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non
2539 segue questa convenzione e restituisce sempre $0$ in caso di successo e $-1$
2540 in caso di errore; questo perché $-1$ è anche un valore di \textit{nice}
2541 legittimo e questo comporta una confusione con una eventuale condizione di
2542 errore. La \textit{system call} originaria inoltre non consente, se non dotati
2543 di adeguati privilegi, di diminuire un valore di \textit{nice} precedentemente
2546 Fino alla \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
2547 risultato dalla \textit{system call}, violando lo standard, per cui per
2548 ottenere il nuovo valore occorreva una successiva chiamata alla funzione
2549 \func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
2550 reimplementata e non viene più chiamata la omonima \textit{system call}, con
2551 questa versione viene restituito come valore di ritorno il valore di
2552 \textit{nice}, come richiesto dallo standard.\footnote{questo viene fatto
2553 chiamando al suo interno \func{setpriority}, che tratteremo a breve.} In
2554 questo caso l'unico modo per rilevare in maniera affidabile una condizione di
2555 errore è quello di azzerare \var{errno} prima della chiamata della funzione e
2556 verificarne il valore quando \func{nice} restituisce $-1$.
2558 Per leggere il valore di \textit{nice} di un processo occorre usare la
2559 funzione di sistema \funcd{getpriority}, derivata da BSD; il suo prototipo è:
2563 \fhead{sys/resource.h}
2564 \fdecl{int getpriority(int which, int who)}
2565 \fdesc{Legge un valore di \textit{nice}.}
2567 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2568 caso \var{errno} assumerà uno dei valori:
2570 \item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
2571 elencati in tab.~\ref{tab:proc_getpriority}.
2572 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2573 \param{which} e \param{who}.
2577 La funzione permette, a seconda di quanto specificato
2578 nell'argomento \param{which}, di leggere il valore di \textit{nice} di un
2579 processo, di un gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di
2580 un utente indicato dall'argomento \param{who}. Nelle vecchie versioni può
2581 essere necessario includere anche \headfiled{sys/time.h}, questo non è più
2582 necessario con versioni recenti delle librerie, ma è comunque utile per
2585 I valori possibili per \param{which}, ed il tipo di valore che occorre usare
2586 in corrispondenza per \param{who} solo elencati nella legenda di
2587 tab.~\ref{tab:proc_getpriority} insieme ai relativi significati. Usare un
2588 valore nullo per \param{who} indica, a seconda della corrispondente
2589 indicazione usata per \param{which} il processo, il gruppo di processi o
2595 \begin{tabular}[c]{|c|c|l|}
2597 \param{which} & \param{who} & \textbf{Significato} \\
2600 \constd{PRIO\_PROCESS} & \type{pid\_t} & processo \\
2601 \constd{PRIO\_PRGR} & \type{pid\_t} & \textit{process group} (vedi
2602 sez.~\ref{sec:sess_proc_group})\\
2603 \constd{PRIO\_USER} & \type{uid\_t} & utente \\
2606 \caption{Legenda del valore dell'argomento \param{which} e del tipo
2607 dell'argomento \param{who} delle funzioni \func{getpriority} e
2608 \func{setpriority} per le tre possibili scelte.}
2609 \label{tab:proc_getpriority}
2612 In caso di una indicazione che faccia riferimento a più processi, la funzione
2613 restituisce la priorità più alta (cioè il valore più basso) fra quelle dei
2614 processi corrispondenti. Come per \func{nice} $-1$ è un valore possibile
2615 corretto, per cui di nuovo per poter rilevare una condizione di errore è
2616 necessario cancellare sempre \var{errno} prima della chiamata alla funzione e
2617 quando si ottiene un valore di ritorno uguale a $-1$ per verificare che essa
2618 resti uguale a zero.
2620 Analoga a \func{getpriority} è la funzione di sistema \funcd{setpriority} che
2621 permette di impostare la priorità di uno o più processi; il suo prototipo è:
2625 \fhead{sys/resource.h}
2626 \fdecl{int setpriority(int which, int who, int prio)}
2627 \fdesc{Imposta un valore di \textit{nice}.}
2629 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2630 caso \var{errno} assumerà uno dei valori:
2632 \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
2633 sufficienti privilegi.
2634 \item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
2635 elencati in tab.~\ref{tab:proc_getpriority}.
2636 \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
2637 cercato di modificare la priorità di un processo di un altro utente.
2638 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2639 \param{which} e \param{who}.
2643 La funzione imposta la priorità dinamica al valore specificato da \param{prio}
2644 per tutti i processi indicati dagli argomenti \param{which} e \param{who}, per
2645 i quali valgono le stesse considerazioni fatte per \func{getpriority} e lo
2646 specchietto di tab.~\ref{tab:proc_getpriority}.
2648 In questo caso come valore di \param{prio} deve essere specificato il valore
2649 di \textit{nice} da assegnare, e non un incremento (positivo o negativo) come
2650 nel caso di \func{nice}, nell'intervallo fra \const{PRIO\_MIN} ($-20$) e
2651 \const{PRIO\_MAX} ($19$). La funzione restituisce il valore di \textit{nice}
2652 assegnato in caso di successo e $-1$ in caso di errore, e come per \func{nice}
2653 anche in questo caso per rilevare un errore occorre sempre porre a zero
2654 \var{errno} prima della chiamata della funzione, essendo $-1$ un valore di
2655 \textit{nice} valido.
2657 Si tenga presente che solo l'amministratore\footnote{o più precisamente un
2658 processo con la \textit{capability} \const{CAP\_SYS\_NICE}, vedi
2659 sez.~\ref{sec:proc_capabilities}.} ha la possibilità di modificare
2660 arbitrariamente le priorità di qualunque processo. Un utente normale infatti
2661 può modificare solo la priorità dei suoi processi ed in genere soltanto
2662 diminuirla. Fino alla versione di kernel 2.6.12 Linux ha seguito le
2663 specifiche dello standard SUSv3, e come per tutti i sistemi derivati da SysV
2664 veniva richiesto che l'\ids{UID} reale o quello effettivo del processo
2665 chiamante corrispondessero all'\ids{UID} reale (e solo a quello) del processo
2666 di cui si intendeva cambiare la priorità. A partire dalla versione 2.6.12 è
2667 stata adottata la semantica in uso presso i sistemi derivati da BSD (SunOS,
2668 Ultrix, *BSD), in cui la corrispondenza può essere anche con l'\ids{UID}
2671 Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
2672 ordinari poter aumentare la priorità dei propri processi specificando un
2673 valore di \param{prio} negativo. Questa operazione non è possibile però in
2674 maniera indiscriminata, ed in particolare può essere effettuata solo
2675 nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE}
2676 (torneremo su questo in sez.~\ref{sec:sys_resource_limit}).
2678 Infine nonostante i valori siano sempre rimasti gli stessi, il significato del
2679 valore di \textit{nice} è cambiato parecchio nelle progressive riscritture
2680 dello \textit{scheduler} di Linux, ed in particolare a partire dal kernel
2681 2.6.23 l'uso di diversi valori di \textit{nice} ha un impatto molto più forte
2682 nella distribuzione della CPU ai processi. Infatti se viene comunque calcolata
2683 una priorità dinamica per i processi che non ricevono la CPU così che anche
2684 essi possano essere messi in esecuzione, un alto valore di \textit{nice}
2685 corrisponde comunque ad una \textit{time-slice} molto piccola che non cresce
2686 comunque, per cui un processo a bassa priorità avrà davvero scarse possibilità
2687 di essere eseguito in presenza di processi attivi a priorità più alta.
2691 \subsection{Il meccanismo di \textit{scheduling real-time}}
2692 \label{sec:proc_real_time}
2694 Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
2695 le priorità assolute per permettere la gestione di processi real-time. In
2696 realtà nel caso di Linux non si tratta di un vero \textit{hard real-time}, in
2697 quanto in presenza di eventuali interrupt il kernel interrompe l'esecuzione di
2698 un processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
2699 siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
2700 ottenere un sistema effettivamente \textit{hard real-time}. In tal caso
2701 infatti gli interrupt vengono intercettati dall'interfaccia
2702 \textit{real-time} (o nel caso di Adeos gestiti dalle code del nano-kernel),
2703 in modo da poterli controllare direttamente qualora ci sia la necessità di
2704 avere un processo con priorità più elevata di un \textit{interrupt
2705 handler}.} mentre con l'incorrere in un \textit{page fault} si possono
2706 avere ritardi non previsti. Se l'ultimo problema può essere aggirato
2707 attraverso l'uso delle funzioni di controllo della memoria virtuale (vedi
2708 sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
2709 ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
2711 Nonostante questo, ed in particolare con una serie di miglioramenti che sono
2712 stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
2713 dalla versione 2.6.18 sono stati inserite nel kernel una serie di modifiche
2714 che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
2715 \textit{real-time} estendendo il concetto di \textit{preemption} alle
2716 operazioni dello stesso kernel; esistono vari livelli a cui questo può
2717 essere fatto, ottenibili attivando in fase di compilazione una fra le
2718 opzioni \texttt{CONFIG\_PREEMPT\_NONE}, \texttt{CONFIG\_PREEMPT\_VOLUNTARY}
2719 e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
2720 approssimazione di sistema \textit{real-time} usando le priorità assolute.
2721 Occorre farlo però con molta attenzione: se si dà ad un processo una priorità
2722 assoluta e questo finisce in un loop infinito, nessun altro processo potrà
2723 essere eseguito, ed esso sarà mantenuto in esecuzione permanentemente
2724 assorbendo tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
2725 sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
2726 che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
2727 massima priorità assoluta, in modo da poter essere comunque in grado di
2728 rientrare nel sistema.
2730 Quando c'è un processo con priorità assoluta lo \textit{scheduler} lo metterà
2731 in esecuzione prima di ogni processo normale. In caso di più processi sarà
2732 eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
2733 processi con la stessa priorità assoluta questi vengono tenuti in una coda e
2734 tocca al kernel decidere quale deve essere eseguito. Il meccanismo con cui
2735 vengono gestiti questi processi dipende dalla politica di \textit{scheduling}
2736 che si è scelta; lo standard ne prevede due:
2737 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
2738 \item[\textit{First In First Out} (FIFO)] Il processo viene eseguito
2739 fintanto che non cede volontariamente la CPU (con la funzione
2740 \func{sched\_yield}), si blocca, finisce o viene interrotto da un processo a
2741 priorità più alta. Se il processo viene interrotto da uno a priorità più
2742 alta esso resterà in cima alla lista e sarà il primo ad essere eseguito
2743 quando i processi a priorità più alta diverranno inattivi. Se invece lo si
2744 blocca volontariamente sarà posto in coda alla lista (ed altri processi con
2745 la stessa priorità potranno essere eseguiti).
2746 \item[\textit{Round Robin} (RR)] Il comportamento è del tutto analogo a quello
2747 precedente, con la sola differenza che ciascun processo viene eseguito al
2748 massimo per un certo periodo di tempo (la cosiddetta \textit{time-slice})
2749 dopo di che viene automaticamente posto in fondo alla coda dei processi con
2750 la stessa priorità. In questo modo si ha comunque una esecuzione a turno di
2751 tutti i processi, da cui il nome della politica. Solo i processi con la
2752 stessa priorità ed in stato \textit{runnable} entrano nel
2756 Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
2757 le politiche di \textit{scheduling}, passando da \textit{real-time} a
2758 ordinarie o viceversa, che di specificare, in caso di politiche
2759 \textit{real-time}, la eventuale priorità statica; la funzione di sistema è
2760 \funcd{sched\_setscheduler} ed il suo prototipo è:
2764 \fdecl{int sched\_setscheduler(pid\_t pid, int policy, const struct
2766 \fdesc{Imposta priorità e politica di \textit{scheduling}.}
2768 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2769 caso \var{errno} assumerà uno dei valori:
2771 \item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
2772 relativo valore di \param{p} non è valido per la politica scelta.
2773 \item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
2775 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2779 La funzione esegue l'impostazione per il processo specificato dall'argomento
2780 \param{pid}, un valore nullo di questo argomento esegue l'impostazione per il
2781 processo corrente. La politica di \textit{scheduling} è specificata
2782 dall'argomento \param{policy} i cui possibili valori sono riportati in
2783 tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le
2784 politiche \textit{real-time}, quella bassa le politiche ordinarie. Un valore
2785 negativo per \param{policy} mantiene la politica di \textit{scheduling}
2791 \begin{tabular}[c]{|l|p{6cm}|}
2793 \textbf{Politica} & \textbf{Significato} \\
2796 \constd{SCHED\_FIFO} & \textit{Scheduling real-time} con politica
2798 \constd{SCHED\_RR} & \textit{Scheduling real-time} con politica
2799 \textit{Round Robin}. \\
2801 \constd{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\
2802 \constd{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione
2803 ulteriore di lavoro \textit{CPU
2804 intensive} (dal kernel 2.6.16).\\
2805 \constd{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
2806 bassa (dal kernel 2.6.23).\\
2809 \caption{Valori dell'argomento \param{policy} per la funzione
2810 \func{sched\_setscheduler}.}
2811 \label{tab:proc_sched_policy}
2814 % TODO Aggiungere SCHED_DEADLINE, sulla nuova politica di scheduling aggiunta
2815 % con il kernel 3.14, vedi anche Documentation/scheduler/sched-deadline.txt e
2816 % http://lwn.net/Articles/575497/
2818 Con le versioni più recenti del kernel sono state introdotte anche delle
2819 varianti sulla politica di \textit{scheduling} tradizionale per alcuni carichi
2820 di lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
2821 devono essere usate se si vogliono scrivere programmi portabili.
2823 La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
2824 la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo
2825 delle priorità dinamiche fatto dallo \textit{scheduler}, il cosiddetto bonus
2826 di interattività che mira a favorire i processi che si svegliano dallo stato
2827 di \textit{sleep}.\footnote{cosa che accade con grande frequenza per i
2828 processi interattivi, dato che essi sono per la maggior parte del tempo in
2829 attesa di dati in ingresso da parte dell'utente.} La si usa pertanto, come
2830 indica il nome, per processi che usano molta CPU (come programmi di calcolo)
2831 che in questo modo sono leggermente sfavoriti rispetto ai processi interattivi
2832 che devono rispondere a dei dati in ingresso, pur non perdendo il loro valore
2835 La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
2836 si desidera siano eseguiti con la più bassa priorità possibile, ancora più
2837 bassa di un processo con il minimo valore di \textit{nice}. In sostanza la si
2838 può utilizzare per processi che devono essere eseguiti se non c'è niente altro
2839 da fare. Va comunque sottolineato che anche un processo \const{SCHED\_IDLE}
2840 avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
2841 percentuale molto bassa.
2843 Qualora si sia richiesta una politica \textit{real-time} il valore della
2844 priorità statica viene impostato attraverso la struttura
2845 \struct{sched\_param}, riportata in fig.~\ref{fig:sig_sched_param}, il cui
2846 solo campo attualmente definito è \var{sched\_priority}. Il campo deve
2847 contenere il valore della priorità statica da assegnare al processo; lo
2848 standard prevede che questo debba essere assegnato all'interno di un
2849 intervallo fra un massimo ed un minimo che nel caso di Linux sono
2850 rispettivamente 1 e 99.
2852 \begin{figure}[!htbp]
2853 \footnotesize \centering
2854 \begin{minipage}[c]{0.5\textwidth}
2855 \includestruct{listati/sched_param.c}
2858 \caption{La struttura \structd{sched\_param}.}
2859 \label{fig:sig_sched_param}
2862 I processi con politica di \textit{scheduling} ordinaria devono sempre
2863 specificare un valore nullo di \var{sched\_priority} altrimenti si avrà un
2864 errore \errcode{EINVAL}, questo valore infatti non ha niente a che vedere con
2865 la priorità dinamica determinata dal valore di \textit{nice}, che deve essere
2866 impostato con le funzioni viste in precedenza.
2868 Lo standard POSIX.1b prevede che l'intervallo dei valori delle priorità
2869 statiche possa essere ottenuto con le funzioni di sistema
2870 \funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
2875 \fdecl{int sched\_get\_priority\_max(int policy)}
2876 \fdesc{Legge il valore massimo di una priorità statica.}
2877 \fdecl{int sched\_get\_priority\_min(int policy)}
2878 \fdesc{Legge il valore minimo di una priorità statica.}
2880 {Le funzioni ritornano il valore della priorità in caso di successo e $-1$ per
2881 un errore, nel qual caso \var{errno} assumerà il valore:
2883 \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
2887 Le funzioni ritornano rispettivamente i due valori della massima e minima
2888 priorità statica possano essere ottenuti per una delle politiche di
2889 \textit{scheduling} \textit{real-time} indicata dall'argomento \param{policy}.
2891 Si tenga presente che quando si imposta una politica di \textit{scheduling}
2892 real-time per un processo o se ne cambia la priorità statica questo viene
2893 messo in cima alla lista dei processi con la stessa priorità; questo comporta
2894 che verrà eseguito subito, interrompendo eventuali altri processi con la
2895 stessa priorità in quel momento in esecuzione.
2897 Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
2898 esegue sempre il primo della lista, mentre un nuovo processo che torna in
2899 stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
2900 politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
2901 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
2902 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
2903 volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
2904 sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
2905 nel caso che esso sia stato interrotto da un processo a priorità più alta.
2907 Solo un processo con i privilegi di amministratore\footnote{più precisamente
2908 con la capacità \const{CAP\_SYS\_NICE}, vedi
2909 sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
2910 assolute diverse da zero o politiche \const{SCHED\_FIFO} e
2911 \const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
2912 processi che gli appartengono; è cioè richiesto che l'\ids{UID} effettivo del
2913 processo chiamante corrisponda all'\ids{UID} reale o effettivo del processo
2914 indicato con \param{pid}.
2916 Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
2917 \textit{real-time} o modificare la eventuale priorità statica di un loro
2918 processo. A partire da questa versione è divenuto possibile anche per gli
2919 utenti normali usare politiche \textit{real-time} fintanto che la priorità
2920 assoluta che si vuole impostare è inferiore al limite \const{RLIMIT\_RTPRIO}
2921 (vedi sez.~\ref{sec:sys_resource_limit}) ad essi assegnato.
2923 Unica eccezione a questa possibilità sono i processi \const{SCHED\_IDLE}, che
2924 non possono cambiare politica di \textit{scheduling} indipendentemente dal
2925 valore di \const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto
2926 ad una politica \textit{real-time}, un utente può sempre, indipendentemente
2927 dal valore di \const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una
2930 Se si intende operare solo sulla priorità statica di un processo si possono
2931 usare le due funzioni di sistema \funcd{sched\_setparam} e
2932 \funcd{sched\_getparam} che consentono rispettivamente di impostarne e
2933 leggerne il valore, i loro prototipi sono:
2937 \fdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)}
2938 \fdesc{Imposta la priorità statica di un processo.}
2939 \fdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)}
2940 \fdesc{Legge la priorità statica di un processo.}
2942 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2943 caso \var{errno} assumerà uno dei valori:
2945 \item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la
2946 politica usata dal processo.
2947 \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
2949 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2953 Le funzioni richiedono di indicare nell'argomento \param{pid} il processo su
2954 cui operare e usano l'argomento \param{param} per mantenere il valore della
2955 priorità dinamica. Questo è ancora una struttura \struct{sched\_param} ed
2956 assume gli stessi valori già visti per \func{sched\_setscheduler}.
2958 L'uso di \func{sched\_setparam}, compresi i controlli di accesso che vi si
2959 applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
2960 argomento \param{policy} uguale a $-1$. Come per \func{sched\_setscheduler}
2961 specificando $0$ come valore dell'argomento \param{pid} si opera sul processo
2962 corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
2963 politica ordinaria essa ha senso soltanto per quelli \textit{real-time}, dato
2964 che per i primi la priorità statica può essere soltanto nulla. La
2965 disponibilità di entrambe le funzioni può essere verificata controllando la
2966 macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'\textit{header
2967 file} \headfiled{sched.h}.
2969 Se invece si vuole sapere quale è politica di \textit{scheduling} di un
2970 processo si può usare la funzione di sistema \funcd{sched\_getscheduler}, il
2975 \fdecl{int sched\_getscheduler(pid\_t pid)}
2976 \fdesc{Legge la politica di \textit{scheduling}.}
2978 {La funzione ritorna la politica di \textit{scheduling} in caso di successo e
2979 $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
2981 \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
2983 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2987 La funzione restituisce il valore, secondo quanto elencato in
2988 tab.~\ref{tab:proc_sched_policy}, della politica di \textit{scheduling} per il
2989 processo specificato dall'argomento \param{pid}, se questo è nullo viene
2990 restituito il valore relativo al processo chiamante.
2992 L'ultima funzione di sistema che permette di leggere le informazioni relative
2993 ai processi real-time è \funcd{sched\_rr\_get\_interval}, che permette di
2994 ottenere la lunghezza della \textit{time-slice} usata dalla politica
2995 \textit{round robin}; il suo prototipo è:
2999 \fdecl{int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)}
3000 \fdesc{Legge la durata della \textit{time-slice} per lo \textit{scheduling}
3001 \textit{round robin}.}
3003 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
3004 caso \var{errno} assumerà uno dei valori:
3006 \item[\errcode{EINVAL}] l'argomento \param{pid} non è valido.
3007 \item[\errcode{ENOSYS}] la \textit{system call} non è presente (solo per
3009 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3011 ed inoltre anche \errval{EFAULT} nel suo significato generico.}
3014 La funzione restituisce nell'argomento \param{tp} come una struttura
3015 \struct{timespec}, (la cui definizione si può trovare in
3016 fig.~\ref{fig:sys_timeval_struct}) il valore dell'intervallo di tempo usato
3017 per la politica \textit{round robin} dal processo indicato da \ids{PID}. Il
3018 valore dipende dalla versione del kernel, a lungo infatti questo intervallo di
3019 tempo era prefissato e non modificabile ad un valore di 150 millisecondi,
3020 restituito indipendentemente dal \ids{PID} indicato.
3022 Con kernel recenti però è possibile ottenere una variazione della
3023 \textit{time-slice}, modificando il valore di \textit{nice} del processo
3024 (anche se questo non incide assolutamente sulla priorità statica) che come
3025 accennato in precedenza modifica il valore assegnato alla \textit{time-slice}
3026 di un processo ordinario, che però viene usato anche dai processi
3029 Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
3030 consentire agli altri processi di essere eseguiti; la funzione di sistema che
3031 consente di fare tutto questo è \funcd{sched\_yield}, il cui prototipo è:
3035 \fdecl{int sched\_yield(void)}
3036 \fdesc{Rilascia volontariamente l'esecuzione.}
3038 {La funzione ritorna $0$ in caso di successo e teoricamente $-1$ per un
3039 errore, ma su Linux ha sempre successo.}
3043 Questa funzione ha un utilizzo effettivo soltanto quando si usa lo
3044 \textit{scheduling} \textit{real-time}, e serve a far sì che il processo
3045 corrente rilasci la CPU, in modo da essere rimesso in coda alla lista dei
3046 processi con la stessa priorità per permettere ad un altro di essere eseguito;
3047 se però il processo è l'unico ad essere presente sulla coda l'esecuzione non
3048 sarà interrotta. In genere usano questa funzione i processi con politica
3049 \const{SCHED\_FIFO}, per permettere l'esecuzione degli altri processi con pari
3050 priorità quando la sezione più urgente è finita.
3052 La funzione può essere utilizzata anche con processi che usano lo
3053 \textit{scheduling} ordinario, ma in questo caso il comportamento non è ben
3054 definito, e dipende dall'implementazione. Fino al kernel 2.6.23 questo
3055 comportava che i processi venissero messi in fondo alla coda di quelli attivi,
3056 con la possibilità di essere rimessi in esecuzione entro breve tempo, con
3057 l'introduzione del \textit{Completely Fair Scheduler} questo comportamento è
3058 cambiato ed un processo che chiama la funzione viene inserito nella lista dei
3059 processi inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
3060 ripristinare un comportamento analogo al precedente scrivendo il valore 1
3061 nel file \sysctlfiled{kernel/sched\_compat\_yield}.}
3063 L'uso delle funzione nella programmazione ordinaria può essere utile e
3064 migliorare le prestazioni generali del sistema quando si è appena rilasciata
3065 una risorsa contesa con altri processi, e si vuole dare agli altri una
3066 possibilità di approfittarne mettendoli in esecuzione, ma chiamarla senza
3067 necessità, specie se questo avviene ripetutamente all'interno di un qualche
3068 ciclo, può avere invece un forte impatto negativo per la generazione di
3069 \textit{context switch} inutili.
3072 \subsection{Il controllo dello \textit{scheduler} per i sistemi
3074 \label{sec:proc_sched_multiprocess}
3076 \index{effetto~ping-pong|(}
3078 Con il supporto dei sistemi multiprocessore sono state introdotte delle
3079 funzioni che permettono di controllare in maniera più dettagliata la scelta di
3080 quale processore utilizzare per eseguire un certo programma. Uno dei problemi
3081 che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
3082 \textsl{effetto ping-pong}. Può accadere cioè che lo \textit{scheduler},
3083 quando riavvia un processo precedentemente interrotto scegliendo il primo
3084 processore disponibile, lo faccia eseguire da un processore diverso rispetto a
3085 quello su cui era stato eseguito in precedenza. Se il processo passa da un
3086 processore all'altro in questo modo, cosa che avveniva abbastanza di frequente
3087 con i kernel della seria 2.4.x, si ha l'effetto ping-pong.
3089 Questo tipo di comportamento può generare dei seri problemi di prestazioni;
3090 infatti tutti i processori moderni utilizzano una memoria interna (la
3091 \textit{cache}) contenente i dati più usati, che permette di evitare di
3092 eseguire un accesso (molto più lento) alla memoria principale sulla scheda
3093 madre. Chiaramente un processo sarà favorito se i suoi dati sono nella cache
3094 del processore, ma è ovvio che questo può essere vero solo per un processore
3095 alla volta, perché in presenza di più copie degli stessi dati su più
3096 processori, non si potrebbe determinare quale di questi ha la versione dei
3097 dati aggiornata rispetto alla memoria principale.
3099 Questo comporta che quando un processore inserisce un dato nella sua cache,
3100 tutti gli altri processori che hanno lo stesso dato devono invalidarlo, e
3101 questa operazione è molto costosa in termini di prestazioni. Il problema
3102 diventa serio quando si verifica l'effetto ping-pong, in tal caso infatti un
3103 processo \textsl{rimbalza} continuamente da un processore all'altro e si ha
3104 una continua invalidazione della cache, che non diventa mai disponibile.
3106 \itindbeg{CPU~affinity}
3108 Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
3109 di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
3110 un processo possa essere assegnato per l'esecuzione sempre allo stesso
3111 processore. Lo \textit{scheduler} dei kernel della serie 2.4.x aveva una
3112 scarsa \textit{CPU affinity}, e l'effetto ping-pong era comune; con il nuovo
3113 \textit{scheduler} dei kernel della 2.6.x questo problema è stato risolto ed
3114 esso cerca di mantenere il più possibile ciascun processo sullo stesso
3117 \index{effetto~ping-pong|)}
3119 In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
3120 sempre eseguito dallo stesso processore,\footnote{quella che viene detta
3121 \textit{hard CPU affinity}, in contrasto con quella fornita dallo
3122 \textit{scheduler}, detta \textit{soft CPU affinity}, che di norma indica
3123 solo una preferenza, non un requisito assoluto.} e per poter risolvere
3124 questo tipo di problematiche nei nuovi kernel\footnote{le due \textit{system
3125 call} per la gestione della \textit{CPU affinity} sono state introdotte
3126 nel kernel 2.5.8, e le corrispondenti funzioni di sistema nella
3127 \textsl{glibc} 2.3.} è stata introdotta l'opportuna infrastruttura ed una
3128 nuova \textit{system call} che permette di impostare su quali processori far
3129 eseguire un determinato processo attraverso una \textsl{maschera di
3130 affinità}. La corrispondente funzione di sistema è
3131 \funcd{sched\_setaffinity} ed il suo prototipo è:
3133 \index{insieme~di~processori|(}
3137 \fdecl{int sched\_setaffinity(pid\_t pid, size\_t setsize,
3139 \fdesc{Imposta la maschera di affinità di un processo.}
3141 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
3142 caso \var{errno} assumerà uno dei valori:
3144 \item[\errcode{EINVAL}] il valore di \param{mask} contiene riferimenti a
3145 processori non esistenti nel sistema o a cui non è consentito l'accesso.
3146 \item[\errcode{EPERM}] il processo non ha i privilegi sufficienti per
3147 eseguire l'operazione.
3148 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3150 ed inoltre anche \errval{EFAULT} nel suo significato generico.}
3153 Questa funzione e la corrispondente \func{sched\_getaffinity} hanno una storia
3154 abbastanza complessa, la sottostante \textit{system call} infatti prevede
3155 l'uso di due soli argomenti (per il pid e l'indicazione della maschera dei
3156 processori), che corrispondono al fatto che l'implementazione effettiva usa
3157 una semplice maschera binaria. Quando le funzioni vennero incluse nella
3158 \acr{glibc} assunsero invece un prototipo simile a quello mostrato però con il
3159 secondo argomento di tipo \ctyp{unsigned int}. A complicare la cosa si
3160 aggiunge il fatto che nella versione 2.3.3 della \acr{glibc} detto argomento
3161 venne stato eliminato, per poi essere ripristinato nella versione 2.3.4 nella
3162 forma attuale.\footnote{pertanto se la vostra pagina di manuale non è
3163 aggiornata, o usate quella particolare versione della \acr{glibc}, potrete
3164 trovare indicazioni diverse, il prototipo illustrato è quello riportato
3165 nella versione corrente (maggio 2008) delle pagine di manuale e
3166 corrispondente alla definizione presente in \headfile{sched.h}.}
3168 La funzione imposta, con l'uso del valore contenuto all'indirizzo
3169 \param{mask}, l'insieme dei processori sui quali deve essere eseguito il
3170 processo identificato tramite il valore passato in \param{pid}. Come in
3171 precedenza il valore nullo di \param{pid} indica il processo corrente. Per
3172 poter utilizzare questa funzione sono richiesti i privilegi di amministratore
3173 (è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
3174 un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
3175 questa viene ereditata attraverso una \func{fork}, in questo modo diventa
3176 possibile legare automaticamente un gruppo di processi ad un singolo
3179 Nell'uso comune, almeno con i kernel successivi alla serie 2.6.x, l'uso di
3180 questa funzione non è necessario, in quanto è lo \textit{scheduler} stesso che
3181 provvede a mantenere al meglio l'affinità di processore. Esistono però
3182 esigenze particolari, ad esempio quando un processo (o un gruppo di processi)
3183 è utilizzato per un compito importante (ad esempio per applicazioni
3184 \textit{real-time} o la cui risposta è critica) e si vuole la massima
3185 velocità, e con questa interfaccia diventa possibile selezionare gruppi di
3186 processori utilizzabili in maniera esclusiva. Lo stesso dicasi quando
3187 l'accesso a certe risorse (memoria o periferiche) può avere un costo diverso a
3188 seconda del processore, come avviene nelle architetture NUMA
3189 (\textit{Non-Uniform Memory Access}).
3191 Infine se un gruppo di processi accede alle stesse risorse condivise (ad
3192 esempio una applicazione con più \textit{thread}) può avere senso usare lo
3193 stesso processore in modo da sfruttare meglio l'uso della sua cache; questo
3194 ovviamente riduce i benefici di un sistema multiprocessore nell'esecuzione
3195 contemporanea dei \textit{thread}, ma in certi casi (quando i \textit{thread}
3196 sono inerentemente serializzati nell'accesso ad una risorsa) possono esserci
3197 sufficienti vantaggi nell'evitare la perdita della cache da rendere
3198 conveniente l'uso dell'affinità di processore.
3200 Dato che il numero di processori può variare a seconda delle architetture, per
3201 semplificare l'uso dell'argomento \param{mask} la \acr{glibc} ha introdotto un
3202 apposito dato di tipo, \typed{cpu\_set\_t},\footnote{questa è una estensione
3203 specifica della \acr{glibc}, da attivare definendo la macro
3204 \macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per questo
3205 tipo di interfaccia e POSIX al momento non prevede nulla al riguardo.} che
3206 permette di identificare un insieme di processori. Il dato è normalmente una
3207 maschera binaria: nei casi più comuni potrebbe bastare un intero a 32 bit, in
3208 cui ogni bit corrisponde ad un processore, ma oggi esistono architetture in
3209 cui questo numero può non essere sufficiente, e per questo è stato creato
3210 questo tipo opaco e una interfaccia di gestione che permette di usare a basso
3211 livello un tipo di dato qualunque rendendosi indipendenti dal numero di bit e
3212 dalla loro disposizione. Per questo le funzioni richiedono anche che oltre
3213 all'insieme di processori si indichi anche la dimensione dello stesso con
3214 l'argomento \param{setsize}, per il quale, se non si usa l'allocazione
3215 dinamica che vedremo a breve, ed è in genere sufficiente passare il valore
3216 \code{sizeof(cpu\_set\_t)}.
3218 L'interfaccia di gestione degli insiemi di processori, oltre alla definizione
3219 del tipo \type{cpu\_set\_t}, prevede una serie di macro di preprocessore per
3220 la manipolazione degli stessi. Quelle di base, che consentono rispettivamente
3221 di svuotare un insieme, di aggiungere o togliere un processore o di verificare
3222 se esso è già presente in un insieme, sono le seguenti:
3228 \fdecl{void \macrod{CPU\_ZERO}(cpu\_set\_t *set)}
3229 \fdesc{Inizializza un insieme di processori vuoto \param{set}.}
3230 \fdecl{void \macrod{CPU\_SET}(int cpu, cpu\_set\_t *set)}
3231 \fdesc{Inserisce il processore \param{cpu} nell'insieme di
3232 processori \param{set}.}
3233 \fdecl{void \macrod{CPU\_CLR}(int cpu, cpu\_set\_t *set)}
3234 \fdesc{Rimuove il processore \param{cpu} nell'insieme di
3235 processori \param{set}.}
3236 \fdecl{int \macrod{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
3237 \fdesc{Controlla se il processore \param{cpu} è nell'insieme di
3238 processori \param{set}.}
3242 Queste macro che sono ispirate dalle analoghe usate per gli insiemi di
3243 \textit{file descriptor} (vedi sez.~\ref{sec:file_select}) e sono state
3244 introdotte con la versione 2.3.3 della \acr{glibc}. Tutte richiedono che si
3245 specifichi il numero di una CPU nell'argomento \param{cpu}, ed un insieme su
3246 cui operare. L'unica che ritorna un risultato è \macro{CPU\_ISSET}, che
3247 restituisce un intero da usare come valore logico (zero se la CPU non è
3248 presente, diverso da zero se è presente).
3250 \itindbeg{side~effects}
3251 Si tenga presente che trattandosi di macro l'argomento \param{cpu} può essere
3252 valutato più volte. Questo significa ad esempio che non si può usare al suo
3253 posto una funzione o un'altra macro, altrimenti queste verrebbero eseguite più
3254 volte, l'argomento cioè non deve avere \textsl{effetti collaterali} (in gergo
3255 \textit{side effects}).\footnote{nel linguaggio C si
3256 parla appunto di \textit{side effects} quando si usano istruzioni la cui
3257 valutazione comporta effetti al di fuori dell'istruzione stessa, come il
3258 caso indicato in cui si passa una funzione ad una macro che usa l'argomento
3259 al suo interno più volte, o si scrivono espressioni come \code{a=a++} in cui
3260 non è chiaro se prima avvenga l'incremento e poi l'assegnazione, ed il cui
3261 risultato dipende dall'implementazione del compilatore.}
3262 \itindend{side~effects}
3265 Le CPU sono numerate da zero (che indica la prima disponibile) fino ad
3266 un numero massimo che dipende dalla architettura hardware. La costante
3267 \constd{CPU\_SETSIZE} indica il numero massimo di processori che possono far
3268 parte di un insieme (al momento vale sempre 1024), e costituisce un limite
3269 massimo al valore dell'argomento \param{cpu}.
3270 Dalla versione 2.6 della \acr{glibc} alle precedenti macro è stata aggiunta,
3271 per contare il numero di processori in un insieme, l'ulteriore:
3277 \fdecl{int \macrod{CPU\_COUNT}(cpu\_set\_t *set)}
3278 \fdesc{Conta il numero di processori presenti nell'insieme \param{set}.}
3282 A partire dalla versione 2.7 della \acr{glibc} sono state introdotte altre
3283 macro che consentono ulteriori manipolazioni, in particolare si possono
3284 compiere delle operazioni logiche sugli insiemi di processori con:
3290 \fdecl{void \macrod{CPU\_AND}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
3291 \fdesc{Esegue l'AND logico di due insiemi di processori.}
3292 \fdecl{void \macrod{CPU\_OR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
3293 \fdesc{Esegue l'OR logico di due insiemi di processori.}
3294 \fdecl{void \macrod{CPU\_XOR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
3295 \fdesc{Esegue lo XOR logico di due insiemi di processori.}
3296 \fdecl{int \macrod{CPU\_EQUAL}(cpu\_set\_t *set1, cpu\_set\_t *set2)}
3297 \fdesc{Verifica se due insiemi di processori sono uguali.}
3301 Le prime tre macro richiedono due insiemi di partenza, \param{srcset1}
3302 e \param{srcset2} e forniscono in un terzo insieme \param{destset} (che può
3303 essere anche lo stesso di uno dei precedenti) il risultato della rispettiva
3304 operazione logica sui contenuti degli stessi. In sostanza con \macro{CPU\_AND}
3305 si otterrà come risultato l'insieme che contiene le CPU presenti in entrambi
3306 gli insiemi di partenza, con \macro{CPU\_OR} l'insieme che contiene le CPU
3307 presenti in uno qualunque dei due insiemi di partenza, e con \macro{CPU\_XOR}
3308 l'insieme che contiene le CPU presenti presenti in uno solo dei due insiemi di
3309 partenza. Infine \macro{CPU\_EQUAL} confronta due insiemi ed è l'unica che
3310 restituisce un intero, da usare come valore logico che indica se sono
3313 Inoltre, sempre a partire dalla versione 2.7 della \acr{glibc}, è stata
3314 introdotta la possibilità di una allocazione dinamica degli insiemi di
3315 processori, per poterli avere di dimensioni corrispondenti al numero di CPU
3316 effettivamente in gioco, senza dover fare riferimento necessariamente alla
3317 precedente dimensione preimpostata di 1024. Per questo motivo sono state
3318 definite tre ulteriori macro, che consentono rispettivamente di allocare,
3319 disallocare ed ottenere la dimensione in byte di un insieme di processori:
3325 \fdecl{cpu\_set\_t * \macrod{CPU\_ALLOC}(num\_cpus)}
3326 \fdesc{Alloca dinamicamente un insieme di processori di dimensione voluta.}
3327 \fdecl{void \macrod{CPU\_FREE}(cpu\_set\_t *set)}
3328 \fdesc{Disalloca un insieme di processori allocato dinamicamente.}
3329 \fdecl{size\_t \macrod{CPU\_ALLOC\_SIZE}(num\_cpus)}
3330 \fdesc{Ritorna la dimensione di un insieme di processori allocato dinamicamente.}
3334 La prima macro, \macro{CPU\_ALLOC}, restituisce il puntatore ad un insieme di
3335 processori in grado di contenere almeno \param{num\_cpus} che viene allocato
3336 dinamicamente. Ogni insieme così allocato dovrà essere disallocato con
3337 \macro{CPU\_FREE} passandogli un puntatore ottenuto da una precedente
3338 \macro{CPU\_ALLOC}. La terza macro, \macro{CPU\_ALLOC\_SIZE}, consente di
3339 ottenere la dimensione in byte di un insieme allocato dinamicamente che
3340 contenga \param{num\_cpus} processori.
3342 Dato che le dimensioni effettive possono essere diverse le macro di gestione e
3343 manipolazione che abbiamo trattato in precedenza non si applicano agli insiemi
3344 allocati dinamicamente, per i quali dovranno sono state definite altrettante
3345 macro equivalenti contraddistinte dal suffisso \texttt{\_S}, che effettuano le
3346 stesse operazioni, ma richiedono in più un argomento
3347 aggiuntivo \param{setsize} che deve essere assegnato al valore ottenuto con
3348 \macro{CPU\_ALLOC\_SIZE}. Questo stesso valore deve essere usato per l'omonimo
3349 argomento delle funzioni \func{sched\_setaffinity} o \func{sched\_getaffinity}
3350 quando si vuole usare per l'argomento che indica la maschera di affinità un
3351 insieme di processori allocato dinamicamente.
3353 \index{insieme~di~processori|)}
3355 A meno di non aver utilizzato \func{sched\_setaffinity}, in condizioni
3356 ordinarie la maschera di affinità di un processo è preimpostata dal sistema in
3357 modo che esso possa essere eseguito su qualunque processore. Se ne può
3358 comunque ottenere il valore corrente usando la funzione di sistema
3359 \funcd{sched\_getaffinity}, il cui prototipo è:
3363 \fdecl{int sched\_getaffinity (pid\_t pid, size\_t setsize,
3365 \fdesc{Legge la maschera di affinità di un processo.}
3367 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
3368 caso \var{errno} assumerà uno dei valori:
3370 \item[\errcode{EINVAL}] \param{setsize} è più piccolo delle dimensioni
3371 della maschera di affinità usata dal kernel.
3372 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3374 ed inoltre anche \errval{EFAULT} nel suo significato generico.}
3377 La funzione restituirà all'indirizzo specificato da \param{mask} il valore
3378 della maschera di affinità del processo indicato dall'argomento \param{pid}
3379 (al solito un valore nullo indica il processo corrente) così da poterla
3380 riutilizzare per una successiva reimpostazione.
3382 È chiaro che queste funzioni per la gestione dell'affinità hanno significato
3383 soltanto su un sistema multiprocessore, esse possono comunque essere
3384 utilizzate anche in un sistema con un processore singolo, nel qual caso però
3385 non avranno alcun risultato effettivo.
3387 \itindend{scheduler}
3388 \itindend{CPU~affinity}
3391 \subsection{Le priorità per le operazioni di I/O}
3392 \label{sec:io_priority}
3394 A lungo l'unica priorità usata per i processi è stata quella relativa
3395 all'assegnazione dell'uso del processore. Ma il processore non è l'unica
3396 risorsa che i processi devono contendersi, un'altra, altrettanto importante
3397 per le prestazioni, è quella dell'accesso a disco. Per questo motivo nello
3398 sviluppo del kernel sono stati introdotti diversi \textit{I/O scheduler} in
3399 grado di distribuire in maniera opportuna questa risorsa ai vari processi.
3401 Fino al kernel 2.6.17 era possibile soltanto differenziare le politiche
3402 generali di gestione, scegliendo di usare un diverso \textit{I/O scheduler}. A
3403 partire da questa versione, con l'introduzione dello \textit{scheduler} CFQ
3404 (\textit{Completely Fair Queuing}) è divenuto possibile, qualora si usi questo
3405 \textit{scheduler}, impostare anche delle diverse priorità di accesso per i
3406 singoli processi.\footnote{al momento (kernel 2.6.31), le priorità di I/O sono
3407 disponibili soltanto per questo \textit{scheduler}.}
3409 La scelta di uno \textit{scheduler} di I/O si può fare in maniera generica per
3410 tutto il sistema all'avvio del kernel con il parametro di avvio
3411 \texttt{elevator},\footnote{per la trattazione dei parametri di avvio del
3412 kernel si rimanda al solito alla sez.~5.3 di \cite{AGL}.} cui assegnare il
3413 nome dello \textit{scheduler}, ma se ne può anche indicare uno specifico per
3414 l'accesso al singolo disco scrivendo nel file
3415 \texttt{/sys/block/\textit{<dev>}/queue/scheduler} (dove
3416 \texttt{\textit{<dev>}} è il nome del dispositivo associato al disco).
3418 Gli \textit{scheduler} disponibili sono mostrati dal contenuto dello stesso
3419 file che riporta fra parentesi quadre quello attivo, il default in tutti i
3420 kernel recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica
3421 appunto lo \textit{scheduler} CFQ.} che supporta le priorità. Per i dettagli
3422 sulle caratteristiche specifiche degli altri \textit{scheduler}, la cui
3423 discussione attiene a problematiche di ambito sistemistico, si consulti la
3424 documentazione nella directory \texttt{Documentation/block/} dei sorgenti del
3427 Una volta che si sia impostato lo \textit{scheduler} CFQ ci sono due
3428 specifiche \textit{system call}, specifiche di Linux, che consentono di
3429 leggere ed impostare le priorità di I/O.\footnote{se usate in corrispondenza
3430 ad uno \textit{scheduler} diverso il loro utilizzo non avrà alcun effetto.}
3431 Dato che non esiste una interfaccia diretta nella \acr{glibc} per queste due
3432 funzioni\footnote{almeno al momento della scrittura di questa sezione, con la
3433 versione 2.11 della \acr{glibc}.} occorrerà invocarle tramite la funzione
3434 \func{syscall} (come illustrato in sez.~\ref{sec:proc_syscall}). Le due
3435 \textit{system call} sono \funcd{ioprio\_get} ed \funcd{ioprio\_set}; i
3436 rispettivi prototipi sono:
3439 \fhead{linux/ioprio.h}
3440 \fdecl{int ioprio\_get(int which, int who)}
3441 \fdesc{Legge la priorità di I/O di un processo.}
3442 \fdecl{int ioprio\_set(int which, int who, int ioprio)}
3443 \fdesc{Imposta la priorità di I/O di un processo.}
3445 {Le funzioni ritornano rispettivamente un intero positivo o 0 in caso di
3446 successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
3449 \item[\errcode{EINVAL}] i valori di \param{which} o di \param{ioprio} non
3451 \item[\errcode{EPERM}] non si hanno i privilegi per eseguire
3452 l'impostazione (solo per \func{ioprio\_set}).
3453 \item[\errcode{ESRCH}] non esiste un processo corrispondente alle indicazioni.
3457 Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
3458 dei due argomenti \param{which} e \param{who} che hanno lo stesso significato
3459 già visto per gli omonimi argomenti di \func{getpriority} e
3460 \func{setpriority}. Anche in questo caso si deve specificare il valore
3461 di \param{which} tramite le opportune costanti riportate in
3462 tab.~\ref{tab:ioprio_args} che consentono di indicare un singolo processo, i
3463 processi di un \textit{process group} (tratteremo questo argomento in
3464 sez.~\ref{sec:sess_proc_group}) o tutti i processi di un utente.
3469 \begin{tabular}[c]{|c|c|l|}
3471 \param{which} & \param{who} & \textbf{Significato} \\
3474 \constd{IPRIO\_WHO\_PROCESS} & \type{pid\_t} & processo\\
3475 \constd{IPRIO\_WHO\_PRGR} & \type{pid\_t} & \textit{process group}\\
3476 \constd{IPRIO\_WHO\_USER} & \type{uid\_t} & utente\\
3479 \caption{Legenda del valore dell'argomento \param{which} e del tipo
3480 dell'argomento \param{who} delle funzioni \func{ioprio\_get} e
3481 \func{ioprio\_set} per le tre possibili scelte.}
3482 \label{tab:ioprio_args}
3485 In caso di successo \func{ioprio\_get} restituisce un intero positivo che
3486 esprime il valore della priorità di I/O, questo valore è una maschera binaria
3487 composta da due parti, una che esprime la \textsl{classe} di
3488 \textit{scheduling} di I/O del processo, l'altra che esprime, quando la classe
3489 di \textit{scheduling} lo prevede, la priorità del processo all'interno della
3490 classe stessa. Questo stesso formato viene utilizzato per indicare il valore
3491 della priorità da impostare con l'argomento \param{ioprio} di
3497 \begin{tabular}[c]{|l|p{8cm}|}
3499 \textbf{Macro} & \textbf{Significato}\\
3502 \macrod{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
3503 & Dato il valore di una priorità come
3504 restituito da \func{ioprio\_get} estrae il
3505 valore della classe.\\
3506 \macrod{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
3507 & Dato il valore di una priorità come
3508 restituito da \func{ioprio\_get} estrae il
3509 valore della priorità.\\
3510 \macrod{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
3511 & Dato un valore di priorità ed una classe
3512 ottiene il valore numerico da passare a
3513 \func{ioprio\_set}.\\
3516 \caption{Le macro per la gestione dei valori numerici .}
3517 \label{tab:IOsched_class_macro}
3521 Per la gestione dei valori che esprimono le priorità di I/O sono state
3522 definite delle opportune macro di preprocessore, riportate in
3523 tab.~\ref{tab:IOsched_class_macro}. I valori delle priorità si ottengono o si
3524 impostano usando queste macro. Le prime due si usano con il valore restituito
3525 da \func{ioprio\_get} e per ottenere rispettivamente la classe di
3526 \textit{scheduling}\footnote{restituita dalla macro con i valori di
3527 tab.~\ref{tab:IOsched_class}.} e l'eventuale valore della priorità. La terza
3528 macro viene invece usata per creare un valore di priorità da usare come
3529 argomento di \func{ioprio\_set} per eseguire una impostazione.
3534 \begin{tabular}[c]{|l|l|}
3536 \textbf{Classe} & \textbf{Significato} \\
3539 \const{IOPRIO\_CLASS\_RT} & \textit{Scheduling} di I/O
3540 \textit{real-time}.\\
3541 \const{IOPRIO\_CLASS\_BE} & \textit{Scheduling} di I/O ordinario.\\
3542 \const{IOPRIO\_CLASS\_IDLE}& \textit{Scheduling} di I/O di priorità
3546 \caption{Costanti che identificano le classi di \textit{scheduling} di I/O.}
3547 \label{tab:IOsched_class}
3550 Le classi di \textit{scheduling} previste dallo \textit{scheduler} CFQ sono
3551 tre, e ricalcano tre diverse modalità di distribuzione delle risorse analoghe
3552 a quelle già adottate anche nel funzionamento dello \textit{scheduler} del
3553 processore. Ciascuna di esse è identificata tramite una opportuna costante,
3554 secondo quanto riportato in tab.~\ref{tab:IOsched_class}.
3556 La classe di priorità più bassa è \constd{IOPRIO\_CLASS\_IDLE}; i processi in
3557 questa classe riescono ad accedere a disco soltanto quando nessun altro
3558 processo richiede l'accesso. Occorre pertanto usarla con molta attenzione,
3559 perché un processo in questa classe può venire completamente bloccato quando
3560 ci sono altri processi in una qualunque delle altre due classi che stanno
3561 accedendo al disco. Quando si usa questa classe non ha senso indicare un
3562 valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
3563 priorità è identica, la minima possibile, per tutti i processi.
3565 La seconda classe di priorità di I/O è \constd{IOPRIO\_CLASS\_BE} (il nome sta
3566 per \textit{best-effort}) che è quella usata ordinariamente da tutti
3567 processi. In questo caso esistono priorità diverse che consentono di
3568 assegnazione di una maggiore banda passante nell'accesso a disco ad un
3569 processo rispetto agli altri, con meccanismo simile a quello dei valori di
3570 \textit{nice} in cui si evita che un processo a priorità più alta possa
3571 bloccare indefinitamente quelli a priorità più bassa. In questo caso però le
3572 diverse priorità sono soltanto otto, indicate da un valore numerico fra 0 e 7
3573 e come per \textit{nice} anche in questo caso un valore più basso indica una
3577 Infine la classe di priorità di I/O \textit{real-time}
3578 \constd{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
3579 processo in questa classe ha sempre la precedenza nell'accesso a disco
3580 rispetto a tutti i processi delle altre classi e di un processo nella stessa
3581 classe ma con priorità inferiore, ed è pertanto in grado di bloccare
3582 completamente tutti gli altri. Anche in questo caso ci sono 8 priorità diverse
3583 con un valore numerico fra 0 e 7, con una priorità più elevata per valori più
3586 In generale nel funzionamento ordinario la priorità di I/O di un processo
3587 viene impostata in maniera automatica nella classe \const{IOPRIO\_CLASS\_BE}
3588 con un valore ottenuto a partire dal corrispondente valore di \textit{nice}
3589 tramite la formula: $\mathtt{\mathit{prio}}=(\mathtt{\mathit{nice}}+20)/5$. Un
3590 utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità
3591 dei processi che gli appartengono,\footnote{per la modifica delle priorità di
3592 altri processi occorrono privilegi amministrativi, ed in particolare la
3593 capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
3594 cioè quelli il cui \ids{UID} reale corrisponde all'\ids{UID} reale o effettivo
3595 del chiamante. Data la possibilità di ottenere un blocco totale del sistema,
3596 solo l'amministratore\footnote{o un processo con la capacità
3597 \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
3598 impostare un processo ad una priorità di I/O nella classe
3599 \const{IOPRIO\_CLASS\_RT}, lo stesso privilegio era richiesto anche per la
3600 classe \const{IOPRIO\_CLASS\_IDLE} fino al kernel 2.6.24, ma dato che in
3601 questo caso non ci sono effetti sugli altri processi questo limite è stato
3602 rimosso a partire dal kernel 2.6.25.
3604 %TODO verificare http://lwn.net/Articles/355987/
3606 \section{Funzioni di gestione avanzata}
3607 \label{sec:proc_advanced_control}
3609 Nelle precedenti sezioni si sono trattate la gran parte delle funzioni che
3610 attengono alla gestione ordinaria dei processi e delle loro proprietà più
3611 comuni. Tratteremo qui alcune \textit{system call} dedicate alla gestione di
3612 funzionalità dei processi molto specifiche ed avanzate, il cui uso è in genere
3613 piuttosto ridotto. Trattandosi di problematiche abbastanza complesse, che
3614 spesso presuppongono la conoscenza di altri argomenti trattati nel seguito
3615 della guida, si può saltare questa sezione in una prima lettura, tornando su
3616 di essa in un secondo tempo.
3619 \subsection{La funzione \func{prctl}}
3620 \label{sec:process_prctl}
3622 Benché la gestione ordinaria possa essere effettuata attraverso le funzioni
3623 che abbiamo già esaminato nelle sezioni precedenti, esistono una serie di
3624 proprietà e caratteristiche particolari dei processi non coperte da esse, per
3625 la cui gestione è stata predisposta una apposita \textit{system call} che
3626 fornisce una interfaccia generica per tutte le operazioni specialistiche. La
3627 funzione di sistema è \funcd{prctl} ed il suo prototipo è:\footnote{la
3628 funzione non è standardizzata ed è specifica di Linux, anche se ne esiste
3629 una analoga in IRIX; è stata introdotta con il kernel 2.1.57.}
3633 \fdecl{int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned
3635 \phantom{int prctl(}unsigned long arg5)}
3636 \fdesc{Esegue una operazione speciale sul processo corrente.}
3638 {La funzione ritorna $0$ o un valore positivo dipendente dall'operazione in
3639 caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà
3640 valori diversi a seconda del tipo di operazione richiesta (in genere
3641 \errval{EINVAL} o \errval{EPERM}).}
3644 La funzione ritorna un valore nullo o positivo in caso di successo e $-1$ in
3645 caso di errore; il significato degli argomenti della funzione successivi al
3646 primo, il valore di ritorno in caso di successo, il tipo di errore restituito
3647 in \var{errno} dipendono dall'operazione eseguita, indicata tramite il primo
3648 argomento, \param{option}. Questo è un valore intero che identifica
3649 l'operazione, e deve essere specificato con l'uso di una delle costanti
3650 predefinite del seguente elenco, che illustra quelle disponibili al
3651 momento:\footnote{alla stesura di questa sezione, cioè con il kernel 3.2.}
3653 \begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
3654 \item[\constd{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
3655 \textit{capability} (vedi sez.~\ref{sec:proc_capabilities}). La funzione
3656 ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una
3657 delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel
3658 \textit{capabilities bounding set} del processo e zero altrimenti,
3659 se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}.
3660 Introdotta a partire dal kernel 2.6.25.
3662 \item[\constd{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
3663 \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e
3664 da tutti i suoi discendenti. La funzione cancella la capacità specificata
3665 nell'argomento \param{arg2} con una delle costanti di
3666 tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del
3667 processo. L'operazione richiede i privilegi di amministratore (la capacità
3668 \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
3669 \errcode{EPERM}; se il valore di \param{arg2} non è valido o se il supporto
3670 per le \textit{file capabilities} non è stato compilato nel kernel la
3671 chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal
3674 \item[\constd{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
3675 terminazione di un processo a causa di un segnale per il quale è prevista la
3676 generazione di un file di \textit{core dump} (vedi
3677 sez.~\ref{sec:sig_standard}) lo genera effettivamente. In genere questo flag
3678 viene attivato automaticamente, ma per evitare problemi di sicurezza (la
3679 generazione di un file da parte di processi privilegiati può essere usata
3680 per sovrascriverne altri) viene cancellato quando si mette in esecuzione un
3681 programma con i bit \acr{suid} e \acr{sgid} attivi (vedi
3682 sez.~\ref{sec:file_special_perm}) o con l'uso delle funzioni per la modifica
3683 degli \ids{UID} dei processi (vedi sez.~\ref{sec:proc_setuid}).
3685 L'operazione è stata introdotta a partire dal kernel 2.3.20, fino al kernel
3686 2.6.12 e per i kernel successivi al 2.6.17 era possibile usare solo un
3687 valore 0 di \param{arg2} per disattivare il flag ed un valore 1 per
3688 attivarlo. Nei kernel dal 2.6.13 al 2.6.17 è stato supportato anche il
3689 valore 2, che causava la generazione di un \textit{core dump} leggibile solo
3690 dall'amministratore, ma questa funzionalità è stata rimossa per motivi di
3691 sicurezza, in quanto consentiva ad un utente normale di creare un file di
3692 \textit{core dump} appartenente all'amministratore in directory dove
3693 l'utente avrebbe avuto permessi di accesso.
3695 \item[\constd{PR\_GET\_DUMPABLE}] Ottiene come valore di ritorno della funzione
3696 lo stato corrente del flag che controlla la effettiva generazione dei
3697 \textit{core dump}. Introdotta a partire dal kernel 2.3.20.
3699 \item[\constd{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
3700 chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
3701 sono: \constd{PR\_ENDIAN\_BIG} (\textit{big endian}),
3702 \constd{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
3703 \constd{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
3704 PowerPC). Introdotta a partire dal kernel 2.6.18, solo per architettura
3707 \item[\constd{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianness} del
3708 processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
3709 essere passata come di tipo ``\ctyp{int *}''. Introdotta a partire dal
3710 kernel 2.6.18, solo su PowerPC.
3712 \item[\constd{PR\_SET\_FPEMU}] Imposta i bit di controllo per l'emulazione
3713 della virgola mobile su architettura ia64, secondo il valore
3714 di \param{arg2}, si deve passare \constd{PR\_FPEMU\_NOPRINT} per emulare in
3715 maniera trasparente l'accesso alle operazioni in virgola mobile, o
3716 \constd{PR\_FPEMU\_SIGFPE} per non emularle ed inviare il segnale
3717 \signal{SIGFPE} (vedi sez.~\ref{sec:sig_prog_error}). Introdotta a partire
3718 dal kernel 2.4.18, solo su architettura ia64.
3720 \item[\constd{PR\_GET\_FPEMU}] Ottiene il valore dei flag di controllo
3721 dell'emulazione della virgola mobile, salvato all'indirizzo puntato
3722 da \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
3723 partire dal kernel 2.4.18, solo su architettura ia64.
3725 \item[\constd{PR\_SET\_FPEXC}] Imposta la modalità delle eccezioni in virgola
3726 mobile (\textit{floating-point exception mode}) al valore di \param{arg2}.
3727 I valori possibili sono:
3729 \item \constd{PR\_FP\_EXC\_SW\_ENABLE} per usare FPEXC per le eccezioni,
3730 \item \constd{PR\_FP\_EXC\_DIV} per la divisione per zero in virgola mobile,
3731 \item \constd{PR\_FP\_EXC\_OVF} per gli overflow,
3732 \item \constd{PR\_FP\_EXC\_UND} per gli underflow,
3733 \item \constd{PR\_FP\_EXC\_RES} per risultati non esatti,
3734 \item \constd{PR\_FP\_EXC\_INV} per operazioni invalide,
3735 \item \constd{PR\_FP\_EXC\_DISABLED} per disabilitare le eccezioni,
3736 \item \constd{PR\_FP\_EXC\_NONRECOV} per usare la modalità di eccezione
3737 asincrona non recuperabile,
3738 \item \constd{PR\_FP\_EXC\_ASYNC} per usare la modalità di eccezione
3739 asincrona recuperabile,
3740 \item \constd{PR\_FP\_EXC\_PRECISE} per la modalità precisa di
3741 eccezione.\footnote{trattasi di gestione specialistica della gestione
3742 delle eccezioni dei calcoli in virgola mobile che, i cui dettagli al
3743 momento vanno al di là dello scopo di questo testo.}
3745 Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
3747 \item[\constd{PR\_GET\_FPEXC}] Ottiene il valore della modalità delle eccezioni
3748 delle operazioni in virgola mobile, salvata all'indirizzo
3749 puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta
3750 a partire dal kernel 2.4.21, solo su PowerPC.
3752 \item[\constd{PR\_SET\_KEEPCAPS}] Consente di controllare quali
3753 \textit{capabilities} vengono cancellate quando si esegue un cambiamento di
3754 \ids{UID} del processo (per i dettagli si veda
3755 sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
3756 pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
3757 per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
3758 mantenute, questo valore viene sempre cancellato attraverso una \func{exec}.
3759 L'uso di questo flag è stato sostituito, a partire dal kernel 2.6.26, dal
3760 flag \const{SECURE\_KEEP\_CAPS} dei \textit{securebits} (vedi
3761 sez.~\ref{sec:proc_capabilities} e l'uso di \const{PR\_SET\_SECUREBITS} più
3762 avanti). Introdotta a partire dal kernel 2.2.18.
3764 \item[\constd{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
3765 il valore del flag di controllo delle \textit{capabilities} impostato con
3766 \const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18.
3768 \item[\constd{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla
3769 stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}''. Il
3770 nome può essere lungo al massimo 16 caratteri, e la stringa deve essere
3771 terminata da NUL se più corta. Introdotta a partire dal kernel 2.6.9.
3773 \item[\constd{PR\_GET\_NAME}] Ottiene il nome del processo chiamante nella
3774 stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}'';
3775 si devono allocare per questo almeno 16 byte, e il nome sarà terminato da
3776 NUL se più corto. Introdotta a partire dal kernel 2.6.9.
3778 \item[\constd{PR\_SET\_PDEATHSIG}] Consente di richiedere l'emissione di un
3779 segnale, che sarà ricevuto dal processo chiamante, in occorrenza della
3780 terminazione del proprio processo padre; in sostanza consente di invertire
3781 il ruolo di \signal{SIGCHLD}. Il valore di \param{arg2} deve indicare il
3782 numero del segnale, o 0 per disabilitare l'emissione. Il valore viene
3783 automaticamente cancellato per un processo figlio creato con \func{fork}.
3784 Introdotta a partire dal kernel 2.1.57.
3786 \item[\constd{PR\_GET\_PDEATHSIG}] Ottiene il valore dell'eventuale segnale
3787 emesso alla terminazione del padre, salvato all'indirizzo
3788 puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
3789 partire dal kernel 2.3.15.
3791 \itindbeg{secure~computing~mode}
3792 \item[\constd{PR\_SET\_SECCOMP}] Imposta il cosiddetto \textit{secure computing
3793 mode} per il processo corrente. Prevede come unica possibilità
3794 che \param{arg2} sia impostato ad 1. Una volta abilitato il \textit{secure
3795 computing mode} il processo potrà utilizzare soltanto un insieme
3796 estremamente limitato di \textit{system call}: \func{read}, \func{write},
3797 \func{\_exit} e \funcm{sigreturn}. Ogni altra \textit{system call} porterà
3798 all'emissione di un \signal{SIGKILL} (vedi sez.~\ref{sec:sig_termination}).
3799 Il \textit{secure computing mode} è stato ideato per fornire un supporto per
3800 l'esecuzione di codice esterno non fidato e non verificabile a scopo di
3801 calcolo;\footnote{lo scopo è quello di poter vendere la capacità di calcolo
3802 della proprio macchina ad un qualche servizio di calcolo distribuito senza
3803 comprometterne la sicurezza eseguendo codice non sotto il proprio
3804 controllo.} in genere i dati vengono letti o scritti grazie ad un socket o
3805 una \textit{pipe}, e per evitare problemi di sicurezza non sono possibili
3806 altre operazioni se non quelle citate. Introdotta a partire dal kernel
3807 2.6.23, disponibile solo se si è abilitato il supporto nel kernel con
3808 \texttt{CONFIG\_SECCOMP}.
3810 % TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
3811 % terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
3812 % Documentation/prctl/seccomp_filter.txt
3813 % vedi anche http://lwn.net/Articles/600250/
3815 % TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
3816 % vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
3818 \item[\constd{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
3819 lo stato corrente del \textit{secure computing mode}, al momento attuale la
3820 funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
3821 che la chiamata di questa funzione in \textit{secure computing mode}
3822 comporterebbe l'emissione di \signal{SIGKILL}, è stata comunque definita per
3823 eventuali estensioni future. Introdotta a partire dal kernel 2.6.23.
3824 \itindend{secure~computing~mode}
3826 \item[\constd{PR\_SET\_SECUREBITS}] Imposta i \textit{securebits} per il
3827 processo chiamante al valore indicato da \param{arg2}; per i dettagli sul
3828 significato dei \textit{securebits} si veda
3829 sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
3830 tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione
3831 richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}),
3832 altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a
3833 partire dal kernel 2.6.26.
3835 \item[\constd{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
3836 funzione l'impostazione corrente per i \textit{securebits}. Introdotta a
3837 partire dal kernel 2.6.26.
3839 \item[\constd{PR\_SET\_TIMING}] Imposta il metodo di temporizzazione del
3840 processo da indicare con il valore di \param{arg2}, attualmente i valori
3841 possibili sono due, con \constd{PR\_TIMING\_STATISTICAL} si usa il metodo
3842 statistico tradizionale, con \constd{PR\_TIMING\_TIMESTAMP} il più accurato
3843 basato su dei \textit{timestamp}, quest'ultimo però non è ancora
3844 implementato ed il suo uso comporta la restituzione di un errore di
3845 \errval{EINVAL}. Introdotta a partire dal kernel 2.6.0-test4.
3847 \item[\constd{PR\_GET\_TIMING}] Ottiene come valore di ritorno della funzione
3848 il metodo di temporizzazione del processo attualmente in uso (uno dei due
3849 valori citati per \const{PR\_SET\_TIMING}). Introdotta a partire dal kernel
3852 \item[\constd{PR\_SET\_TSC}] Imposta il flag che indica se il processo
3853 chiamante può leggere il registro di processore contenente il contatore dei
3854 \textit{timestamp} (TSC, o \textit{Time Stamp Counter}) da indicare con il
3855 valore di \param{arg2}. Si deve specificare \constd{PR\_TSC\_ENABLE} per
3856 abilitare la lettura o \constd{PR\_TSC\_SIGSEGV} per disabilitarla con la
3857 generazione di un segnale di \signal{SIGSEGV} (vedi
3858 sez.~\ref{sec:sig_prog_error}). La lettura viene automaticamente
3859 disabilitata se si attiva il \textit{secure computing mode} (vedi
3860 \const{PR\_SET\_SECCOMP} più avanti). Introdotta a partire dal kernel
3861 2.6.26, solo su x86.
3863 \item[\constd{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
3864 lettura del contattore dei \textit{timestamp}, salvato all'indirizzo
3865 puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
3866 partire dal kernel 2.6.26, solo su x86.
3867 % articoli sul TSC e relativi problemi: http://lwn.net/Articles/209101/,
3868 % http://blog.cr0.org/2009/05/time-stamp-counter-disabling-oddities.html,
3869 % http://en.wikipedia.org/wiki/Time_Stamp_Counter
3871 \item[\constd{PR\_SET\_UNALIGN}] Imposta la modalità di controllo per l'accesso
3872 a indirizzi di memoria non allineati, che in varie architetture risultano
3873 illegali, da indicare con il valore di \param{arg2}. Si deve specificare il
3874 valore \constd{PR\_UNALIGN\_NOPRINT} per ignorare gli accessi non allineati,
3875 ed il valore \constd{PR\_UNALIGN\_SIGBUS} per generare un segnale di
3876 \signal{SIGBUS} (vedi sez.~\ref{sec:sig_prog_error}) in caso di accesso non
3877 allineato. Introdotta con diverse versioni su diverse architetture.
3879 \item[\const{PR\_GET\_UNALIGN}] Ottiene il valore della modalità di controllo
3880 per l'accesso a indirizzi di memoria non allineati, salvato all'indirizzo
3881 puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta con
3882 diverse versioni su diverse architetture.
3883 \item[\const{PR\_MCE\_KILL}] Imposta la politica di gestione degli errori
3884 dovuti a corruzione della memoria per problemi hardware. Questo tipo di
3885 errori vengono riportati dall'hardware di controllo della RAM e vengono
3886 gestiti dal kernel,\footnote{la funzionalità è disponibile solo sulle
3887 piattaforme più avanzate che hanno il supporto hardware per questo tipo di
3888 controlli.} ma devono essere opportunamente riportati ai processi che
3889 usano quella parte di RAM che presenta errori; nel caso specifico questo
3890 avviene attraverso l'emissione di un segnale di \signal{SIGBUS} (vedi
3891 sez.~\ref{sec:sig_prog_error}).\footnote{in particolare viene anche
3892 impostato il valore di \var{si\_code} in \struct{siginfo\_t} a
3893 \const{BUS\_MCEERR\_AO}; per il significato di tutto questo si faccia
3894 riferimento alla trattazione di sez.~\ref{sec:sig_sigaction}.}
3896 Il comportamento di default prevede che per tutti i processi si applichi la
3897 politica generale di sistema definita nel file
3898 \sysctlfiled{vm/memory\_failure\_early\_kill}, ma specificando
3899 per \param{arg2} il valore \constd{PR\_MCE\_KILL\_SET} è possibile impostare
3900 con il contenuto di \param{arg3} una politica specifica del processo
3901 chiamante. Si può tornare alla politica di default del sistema utilizzando
3902 invece per \param{arg2} il valore \constd{PR\_MCE\_KILL\_CLEAR}. In tutti i
3903 casi, per compatibilità con eventuali estensioni future, tutti i valori
3904 degli argomenti non utilizzati devono essere esplicitamente posti a zero,
3905 pena il fallimento della chiamata con un errore di \errval{EINVAL}.
3907 In caso di impostazione di una politica specifica del processo con
3908 \const{PR\_MCE\_KILL\_SET} i valori di \param{arg3} possono essere soltanto
3909 due, che corrispondono anche al valore che si trova nell'impostazione
3910 generale di sistema di \texttt{memory\_failure\_early\_kill}, con
3911 \constd{PR\_MCE\_KILL\_EARLY} si richiede l'emissione immediata di
3912 \signal{SIGBUS} non appena viene rilevato un errore, mentre con
3913 \constd{PR\_MCE\_KILL\_LATE} il segnale verrà inviato solo quando il processo
3914 tenterà un accesso alla memoria corrotta. Questi due valori corrispondono
3915 rispettivamente ai valori 1 e 0 di
3916 \texttt{memory\_failure\_early\_kill}.\footnote{in sostanza nel primo caso
3917 viene immediatamente inviato il segnale a tutti i processi che hanno la
3918 memoria corrotta mappata all'interno del loro spazio degli indirizzi, nel
3919 secondo caso prima la pagina di memoria viene tolta dallo spazio degli
3920 indirizzi di ciascun processo, mentre il segnale viene inviato solo quei
3921 processi che tentano di accedervi.} Si può usare per \param{arg3} anche un
3922 terzo valore, \constd{PR\_MCE\_KILL\_DEFAULT}, che corrisponde a impostare
3923 per il processo la politica di default.\footnote{si presume la politica di
3924 default corrente, in modo da non essere influenzati da un eventuale
3925 successivo cambiamento della stessa.} Introdotta a partire dal kernel
3927 \item[\constd{PR\_MCE\_KILL\_GET}] Ottiene come valore di ritorno della
3928 funzione la politica di gestione degli errori dovuti a corruzione della
3929 memoria. Tutti gli argomenti non utilizzati (al momento tutti) devono essere
3930 nulli pena la ricezione di un errore di \errval{EINVAL}. Introdotta a
3931 partire dal kernel 2.6.32.
3932 \itindbeg{child~reaper}
3933 \item[\constd{PR\_SET\_CHILD\_SUBREAPER}] Se \param{arg2} è diverso da zero
3934 imposta l'attributo di \textit{child reaper} per il processo, se nullo lo
3935 cancella. Lo stato di \textit{child reaper} è una funzionalità, introdotta
3936 con il kernel 3.4, che consente di far svolgere al processo che ha questo
3937 attributo il ruolo di ``\textsl{genitore adottivo}'' per tutti i processi
3938 suoi ``\textsl{discendenti}'' che diventano orfani, in questo modo il
3939 processo potrà ricevere gli stati di terminazione alla loro uscita,
3940 sostituendo in questo ruolo \cmd{init} (si ricordi quanto illustrato in
3941 sez.~\ref{sec:proc_termination}). Il meccanismo è stato introdotto ad uso
3942 dei programmi di gestione dei servizi, per consentire loro di ricevere gli
3943 stati di terminazione di tutti i processi che lanciano, anche se questi
3944 eseguono una doppia \func{fork}; nel comportamento ordinario infatti questi
3945 verrebbero adottati da \cmd{init} ed il programma che li ha lanciati non
3946 sarebbe più in grado di riceverne lo stato di terminazione. Se un processo
3947 con lo stato di \textit{child reaper} termina prima dei suoi discendenti,
3948 svolgerà questo ruolo il più prossimo antenato ad avere lo stato di
3949 \textit{child reaper},
3950 \item[\constd{PR\_GET\_CHILD\_SUBREAPER}] Ottiene l'impostazione relativa allo
3951 lo stato di \textit{child reaper} del processo chiamante, salvata come
3952 \textit{value result} all'indirizzo puntato da \param{arg2} (da indicare
3953 come di tipo \code{int *}). Il valore viene letto come valore logico, se
3954 diverso da 0 lo stato di \textit{child reaper} è attivo altrimenti è
3955 disattivo. Introdotta a partire dal kernel 3.4.
3956 \itindend{child~reaper}
3959 % TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
3960 % * Documentation/prctl/seccomp_filter.txt
3961 % * http://lwn.net/Articles/475043/
3963 % TODO documentare PR_MPX_INIT e PR_MPX_RELEASE, vedi
3964 % http://lwn.net/Articles/582712/
3966 % TODO documentare PR_SET_MM_MAP aggiunta con il kernel 3.18, per impostare i
3967 % parametri di base del layout dello spazio di indirizzi di un processo (area
3968 % codice e dati, stack, brack pointer ecc. vedi
3969 % http://git.kernel.org/linus/f606b77f1a9e362451aca8f81d8f36a3a112139e
3971 % TODO documentare ARCH_SET_CPUID e ARCH_GET_CPUID, introdotte con il kernel
3972 % 4.12, vedi https://lwn.net/Articles/721182/
3975 \label{sec:prctl_operation}
3979 \subsection{La \textit{system call} \func{clone}}
3980 \label{sec:process_clone}
3982 La funzione tradizionale con cui creare un nuovo processo in un sistema
3983 Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con
3984 l'introduzione del supporto del kernel per i \textit{thread} (vedi
3985 cap.~\ref{cha:threads}), si è avuta la necessità di una interfaccia che
3986 consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi
3987 processi, che poi è stata utilizzata anche per fornire supporto per le
3988 tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container}).
3990 Per questo l'interfaccia per la creazione di un nuovo processo è stata
3991 delegata ad una nuova \textit{system call}, \funcm{sys\_clone}, che consente
3992 di reimplementare anche la tradizionale \func{fork}. In realtà in questo caso
3993 più che di nuovi processi si può parlare della creazioni di nuovi
3994 ``\textit{task}'' del kernel che possono assumere la veste sia di un processo
3995 classico isolato dagli altri come quelli trattati finora, che di un
3996 \textit{thread} in cui la memoria viene condivisa fra il processo chiamante ed
3997 il nuovo processo creato, come quelli che vedremo in
3998 sez.~\ref{sec:linux_thread}. Per evitare confusione fra \textit{thread} e
3999 processi ordinari, abbiamo deciso di usare la nomenclatura \textit{task} per
4000 indicare la unità di esecuzione generica messa a disposizione del kernel che
4001 \texttt{sys\_clone} permette di creare.
4003 \itindbeg{namespace}
4004 \itindbeg{container}
4006 Oltre a questo la funzione consente, ad uso delle nuove funzionalità di
4007 virtualizzazione dei processi, di creare nuovi ``\textit{namespace}'' per una
4008 serie di proprietà generali (come l'elenco dei \ids{PID}, l'albero dei file, i
4009 \textit{mount point}, la rete, il sistema di IPC, ecc.). L'uso dei
4010 ``\textit{namespace}'' consente creare gruppi di processi che vedono le
4011 suddette proprietà in maniera indipendente fra loro. I processi di ciascun
4012 gruppo vengono così eseguiti come in una sorta di spazio separato da quello
4013 degli altri gruppi, che costituisce poi quello che viene chiamato un
4016 \itindend{namespace}
4017 \itindend{container}
4019 La \textit{system call} richiede soltanto due argomenti: il
4020 primo, \param{flags}, consente di controllare le modalità di creazione del
4021 nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
4022 dello \textit{stack} per il nuovo \textit{task}, e deve essere indicato quando
4023 si intende creare un \textit{thread}. L'esecuzione del programma creato da
4024 \func{sys\_clone} riprende, come per \func{fork}, da dopo l'esecuzione della
4027 La necessità di avere uno \textit{stack} alternativo c'è solo quando si
4028 intende creare un \textit{thread}, in tal caso infatti il nuovo \textit{task}
4029 vede esattamente la stessa memoria del \textit{task}
4030 ``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
4031 il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
4032 da essa creato, senza nessuna delle implicazioni che il concetto ha per i
4033 processi.} e nella sua esecuzione alla prima chiamata di una funzione
4034 andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi
4035 quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello
4038 Per evitare di doversi garantire contro la evidente possibilità di
4039 \textit{race condition} che questa situazione comporta (vedi
4040 sez.~\ref{sec:proc_race_cond} per una spiegazione della problematica) è
4041 necessario che il chiamante allochi preventivamente un'area di memoria. In
4042 genere lo si fa con una \func{malloc} che allochi un buffer che la funzione
4043 imposterà come \textit{stack} del nuovo processo, avendo ovviamente cura di
4044 non utilizzarlo direttamente nel processo chiamante.
4046 In questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
4047 non si dovranno affrontare problematiche di \textit{race condition}. Si tenga
4048 presente inoltre che in molte architetture di processore lo \textit{stack}
4049 cresce verso il basso, pertanto in tal caso non si dovrà specificare
4050 per \param{child\_stack} il puntatore restituito da \func{malloc}, ma un
4051 puntatore alla fine del buffer da essa allocato.
4053 Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
4054 memoria, la \textit{system call}, a differenza della funzione di libreria che
4055 vedremo a breve, consente anche di passare per \param{child\_stack} il valore
4056 \val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
4057 processo, questo ottiene un suo nuovo spazio degli indirizzi (è sottinteso
4058 cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo a breve) ed
4059 in questo caso si applica la semantica del \textit{copy on write} illustrata
4060 in sez.~\ref{sec:proc_fork}, per cui le pagine dello \textit{stack} verranno
4061 automaticamente copiate come le altre e il nuovo processo avrà un suo
4062 \textit{stack} totalmente indipendente da quello del padre.
4064 Dato che l'uso principale della nuova \textit{system call} è quello relativo
4065 alla creazione dei \textit{thread}, la \acr{glibc} definisce una funzione di
4066 libreria con una sintassi diversa, orientata a questo scopo, e la
4067 \textit{system call} resta accessibile solo se invocata esplicitamente come
4068 visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
4069 \textit{system call} non è disponibile la chiamata veloce con
4070 \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente
4071 \funcd{clone} ed il suo prototipo è:
4075 \fdecl{int clone(int (*fn)(void *), void *child\_stack, int flags, void *arg,
4077 \phantom{int clone(}/* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */ )}
4078 \fdesc{Crea un nuovo processo o \textit{thread}.}
4080 {La funzione ritorna il \textit{Thread ID} assegnato al nuovo processo in caso
4081 di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
4084 \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi.
4085 \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
4086 un valore nullo per \param{child\_stack}.
4087 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
4088 \texttt{task\_struct} o per copiare le parti del contesto del chiamante
4089 necessarie al nuovo \textit{task}.
4090 \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
4091 richiesti dai flag indicati.
4095 % NOTE: una pagina con la descrizione degli argomenti:
4096 % * http://www.lindevdoc.org/wiki/Clone
4098 La funzione prende come primo argomento \param{fn} il puntatore alla funzione
4099 che verrà messa in esecuzione nel nuovo processo, che può avere un unico
4100 argomento di tipo puntatore a \ctyp{void}, il cui valore viene passato dal
4101 terzo argomento \param{arg}. Per quanto il precedente prototipo possa
4102 intimidire nella sua espressione, in realtà l'uso è molto semplice basterà
4103 definire una qualunque funzione \param{fn} che restituisce un intero ed ha
4104 come argomento un puntatore a \ctyp{void}, e \code{fn(arg)} sarà eseguita in
4107 Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn}
4108 non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore
4109 di ritorno della funzione (o quello specificato con \func{exit}) verrà
4110 utilizzato come stato di uscita della funzione. I tre
4111 argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono
4112 presenti solo a partire dal kernel 2.6 e sono stati aggiunti come supporto per
4113 le funzioni di gestione dei \textit{thread} (la \textit{Native Thread Posix
4114 Library}, vedi sez.~\ref{sec:linux_ntpl}) nella \acr{glibc}, essi vengono
4115 utilizzati soltanto se si sono specificati rispettivamente i flag
4116 \const{CLONE\_PARENT\_SETTID}, \const{CLONE\_SETTLS} e
4117 \const{CLONE\_CHILD\_SETTID}.
4119 La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
4120 \texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
4121 al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
4122 un processo ordinario e non un \textit{thread}.
4124 Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
4125 nuovo processo da essa creato, è controllato principalmente
4126 dall'argomento \param{flags}, che deve essere specificato come maschera
4127 binaria, ottenuta con un OR aritmetico di una delle costanti del seguente
4128 elenco, che illustra quelle attualmente disponibili:\footnote{si fa
4129 riferimento al momento della stesura di questa sezione, cioè con il kernel
4132 \begin{basedescript}{\desclabelwidth{1.5 cm}\desclabelstyle{\nextlinelabel}}
4134 \item[\constd{CLONE\_CHILD\_CLEARTID}] cancella il valore del \textit{thread
4135 ID} posto all'indirizzo dato dall'argomento \param{ctid}, eseguendo un
4136 riattivazione del \textit{futex} (vedi sez.~\ref{sec:xxx_futex}) a
4137 quell'indirizzo. Questo flag viene utilizzato dalla librerie di gestione dei
4138 \textit{thread} ed è presente dal kernel 2.5.49.
4140 \item[\constd{CLONE\_CHILD\_SETTID}] scrive il \ids{TID} del \textit{thread}
4141 figlio all'indirizzo dato dall'argomento \param{ctid}. Questo flag viene
4142 utilizzato dalla librerie di gestione dei \textit{thread} ed è presente dal
4145 \item[\constd{CLONE\_FILES}] se impostato il nuovo processo condividerà con il
4146 padre la \textit{file descriptor table} (vedi sez.~\ref{sec:file_fd}),
4147 questo significa che ogni \textit{file descriptor} aperto da un processo
4148 verrà visto anche dall'altro e che ogni chiusura o cambiamento dei
4149 \textit{file descriptor flag} di un \textit{file descriptor} verrà per
4152 Se non viene impostato il processo figlio eredita una copia della
4153 \textit{file descriptor table} del padre e vale la semantica classica della
4154 gestione dei \textit{file descriptor}, che costituisce il comportamento
4155 ordinario di un sistema unix-like e che illustreremo in dettaglio in
4156 sez.~\ref{sec:file_shared_access}.
4158 \item[\constd{CLONE\_FS}] se questo flag viene impostato il nuovo processo
4159 condividerà con il padre le informazioni relative all'albero dei file, ed in
4160 particolare avrà la stessa radice (vedi sez.~\ref{sec:file_chroot}), la
4161 stessa directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la stessa
4162 \textit{umask} (sez.~\ref{sec:file_perm_management}). Una modifica di una
4163 qualunque di queste caratteristiche in un processo, avrà effetto anche
4164 sull'altro. Se assente il nuovo processo riceverà una copia delle precedenti
4165 informazioni, che saranno così indipendenti per i due processi, come avviene
4166 nel comportamento ordinario di un sistema unix-like.
4168 \item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo il nuovo
4169 processo condividerà con il padre il contesto dell'I/O, altrimenti, come
4170 come avviene nel comportamento ordinario con una \func{fork} otterrà un suo
4173 Il contesto dell'I/O viene usato dagli \textit{scheduler} di I/O (visti in
4174 sez.~\ref{sec:io_priority}) e se questo è lo stesso per diversi processi
4175 questi vengono trattati come se fossero lo stesso, condividendo il tempo per
4176 l'accesso al disco, e possono interscambiarsi nell'accesso a disco. L'uso di
4177 questo flag consente, quando più \textit{thread} eseguono dell'I/O per conto
4178 dello stesso processo (ad esempio con le funzioni di I/O asincrono di
4179 sez.~\ref{sec:file_asyncronous_io}), migliori prestazioni.
4181 %TODO : tutti i CLONE_NEW* attengono ai namespace, ed è meglio metterli nella
4182 %relativa sezione da creare a parte
4184 % \item[\constd{CLONE\_NEWIPC}] è uno dei flag ad uso dei \textit{container},
4185 % introdotto con il kernel 2.6.19. L'uso di questo flag crea per il nuovo
4186 % processo un nuovo \textit{namespace} per il sistema di IPC, sia per quello
4187 % di SysV (vedi sez.~\ref{sec:ipc_sysv}) che, dal kernel 2.6.30, per le code
4188 % di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); si applica cioè a
4189 % tutti quegli oggetti che non vegono identificati con un \textit{pathname}
4190 % sull'albero dei file.
4192 % L'uso di questo flag richiede privilegi di amministratore (più precisamente
4193 % la capacità \const{CAP\_SYS\_ADMIN}) e non può essere usato in combinazione
4194 % con \const{CLONE\_SYSVSEM}.
4196 % \item[\constd{CLONE\_NEWNET}]
4197 % \item[\constd{CLONE\_NEWNS}]
4198 % \item[\constd{CLONE\_NEWPID}]
4199 % \item[\constd{CLONE\_NEWUTS}]
4202 % TODO trattare CLONE_NEWCGROUP introdotto con il kernel 4.6, vedi
4203 % http://lwn.net/Articles/680566/
4205 \item[\constd{CLONE\_PARENT}]
4206 \item[\constd{CLONE\_PARENT\_SETTID}]
4207 \item[\constd{CLONE\_PID}]
4209 \item[\constd{CLONE\_PTRACE}] se questo flag viene impostato ed il processo
4210 chiamante viene tracciato (vedi sez.~\ref{sec:process_ptrace}) anche il
4211 figlio viene tracciato.
4213 \item[\constd{CLONE\_SETTLS}]
4214 \item[\constd{CLONE\_SIGHAND}]
4215 \item[\constd{CLONE\_STOPPED}]
4216 \item[\constd{CLONE\_SYSVSEM}]
4217 \item[\constd{CLONE\_THREAD}]
4219 \item[\constd{CLONE\_UNTRACED}] se questo flag viene impostato un processo non
4220 può più forzare \const{CLONE\_PTRACE} su questo processo.
4222 \item[\constd{CLONE\_VFORK}] se questo flag viene impostato il chiamante viene
4223 fermato fintato che il figlio appena creato non rilascia la sua memoria
4224 virtuale con una chiamata a \func{exec} o \func{exit}, viene quindi
4225 replicato il comportamento di \func{vfork}.
4227 \item[\constd{CLONE\_VM}] se questo flag viene impostato il nuovo processo
4228 condividerà con il padre la stessa memoria virtuale, e le scritture in
4229 memoria fatte da uno qualunque dei processi saranno visibili dall'altro,
4230 così come ogni mappatura in memoria (vedi sez.~\ref{sec:file_memory_map}).
4232 Se non viene impostato il processo figlio otterrà una copia dello spazio
4233 degli indirizzi e si otterrà il comportamento ordinario di un processo di un
4234 sistema unix-like creato con la funzione \func{fork}.
4238 %TODO sezione separata sui namespace
4240 %TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/
4242 %TODO: trattare la funzione setns e i namespace file descriptors (vedi
4243 % http://lwn.net/Articles/407495/) introdotti con il kernel 3.0, altre
4244 % informazioni su setns qui: http://lwn.net/Articles/532748/
4245 % http://lwn.net/Articles/531498/
4248 % TODO trattare le funzioni di protezione della memoria pkey_alloc, pkey_free,
4249 % pkey_mprotect, introdotte con il kernel 4.8, vedi
4250 % http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
4252 %TODO trattare kcmp aggiunta con il kernel 3.5, vedi
4253 % https://lwn.net/Articles/478111/
4255 %\subsection{La funzione \func{ptrace}}
4256 %\label{sec:process_ptrace}
4260 % TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
4261 % TODO: trattare PTRACE_O_EXITKILL, aggiunta con il kernel 3.8 (vedi
4262 % http://lwn.net/Articles/529060/)
4263 % TODO: trattare PTRACE_GETSIGMASK e PTRACE_SETSIGMASK introdotte con il
4265 % TODO: trattare PTRACE_O_SUSPEND_SECCOMP, aggiunta con il kernel 4.3, vedi
4266 % http://lwn.net/Articles/656675/
4268 %\subsection{La gestione delle operazioni in virgola mobile}
4269 %\label{sec:process_fenv}
4273 % TODO eccezioni ed arrotondamenti per la matematica in virgola mobile
4274 % consultare la manpage di fenv, math_error, fpclassify, matherr, isgreater,
4275 % isnan, nan, INFINITY
4278 %\subsection{L'accesso alle porte di I/O}
4279 %\label{sec:process_io_port}
4282 % TODO l'I/O sulle porte di I/O
4283 % consultare le manpage di ioperm, iopl e outb
4284 % non c'entra nulla qui, va trovato un altro posto (altri meccanismi di I/O in
4290 %\subsection{La gestione di architetture a nodi multipli}
4291 %\label{sec:process_NUMA}
4293 % TODO trattare i cpuset, che attiene anche a NUMA, e che possono essere usati
4294 % per associare l'uso di gruppi di processori a gruppi di processi (vedi
4296 % TODO trattare getcpu, che attiene anche a NUMA, mettere qui anche
4297 % sched_getcpu, che potrebbe essere indipendente ma richiama getcpu
4299 %TODO trattare le funzionalità per il NUMA
4300 % vedi man numa e, mbind, get_mempolicy, set_mempolicy,
4301 % le pagine di manuale relative
4302 % vedere anche dove metterle...
4304 % \subsection{La gestione dei moduli}
4305 % \label{sec:kernel_modules}
4309 %TODO trattare init_module e finit_module (quest'ultima introdotta con il
4312 %%%% Altre cose di cui non è chiara la collocazione:
4314 %TODO trattare membarrier, introdotta con il kernel 4.3
4315 % vedi http://lwn.net/Articles/369567/ http://lwn.net/Articles/369640/
4316 % http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b25b13ab08f616efd566347d809b4ece54570d1
4317 % vedi anche l'ulteriore opzione "expedited" introdotta con il kernel 4.14
4318 % (https://lwn.net/Articles/728795/)
4320 \section{Problematiche di programmazione multitasking}
4321 \label{sec:proc_multi_prog}
4323 Benché i processi siano strutturati in modo da apparire il più possibile come
4324 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
4325 occorre tenere conto di una serie di problematiche che normalmente non
4326 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
4327 programma alla volta.
4329 Per questo motivo, essendo questo argomento di carattere generale, ci è parso
4330 opportuno introdurre sinteticamente queste problematiche, che ritroveremo a
4331 più riprese in capitoli successivi, in questa sezione conclusiva del capitolo
4332 in cui abbiamo affrontato la gestione dei processi, sottolineando come esse
4333 diventino cogenti quando invece si usano i \textit{thread}.
4336 \subsection{Le operazioni atomiche}
4337 \label{sec:proc_atom_oper}
4339 La nozione di \textsl{operazione atomica} deriva dal significato greco della
4340 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
4341 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
4342 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
4343 di interruzione in una fase intermedia.
4345 In un ambiente multitasking il concetto è essenziale, dato che un processo può
4346 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
4347 altro processo o dalla ricezione di un segnale. Occorre pertanto essere
4348 accorti nei confronti delle possibili \textit{race condition} (vedi
4349 sez.~\ref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase
4350 in cui non erano ancora state completate.
4352 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
4353 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
4354 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
4355 cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
4356 sez.~\ref{sec:file_shared_access}). In questi casi in genere l'uso delle
4357 appropriate funzioni di libreria per compiere le operazioni necessarie è
4358 garanzia sufficiente di atomicità in quanto le \textit{system call} con cui
4359 esse sono realizzate non possono essere interrotte (o subire interferenze
4360 pericolose) da altri processi.
4362 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
4363 stesso processo, e pure alcune \textit{system call}, possono essere interrotti
4364 in qualunque momento, e le operazioni di un eventuale \textit{signal handler}
4365 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
4366 il solo accesso o l'assegnazione di una variabile possono non essere più
4367 operazioni atomiche (torneremo su questi aspetti in
4368 sez.~\ref{sec:sig_adv_control}).
4370 Qualora invece si usino i \textit{thread}, in cui lo spazio degli indirizzi è
4371 condiviso, il problema è sempre presente, perché qualunque \textit{thread} può
4372 interromperne un altro in qualunque momento e l'atomicità di qualunque
4373 operazione è messa in discussione, per cui l'assenza di eventuali \textit{race
4374 condition} (vedi sez.~\ref{sec:proc_race_cond}) deve essere sempre
4375 verificata nei minimi dettagli.
4377 In questo caso il sistema provvede un tipo di dato, il \typed{sig\_atomic\_t},
4378 il cui accesso è assicurato essere atomico. In pratica comunque si può
4379 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
4380 \ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
4381 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
4382 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
4383 le strutture di dati. In tutti questi casi è anche opportuno marcare come
4384 \dirct{volatile} le variabili che possono essere interessate ad accesso
4385 condiviso, onde evitare problemi con le ottimizzazioni del codice.
4389 \subsection{Le \textit{race condition} ed i \textit{deadlock}}
4390 \label{sec:proc_race_cond}
4392 \itindbeg{race~condition}
4394 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
4395 diversi operano su una risorsa comune, ed in cui il risultato viene a
4396 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
4397 tipico è quello di un'operazione che viene eseguita da un processo in più
4398 passi, e può essere compromessa dall'intervento di un altro processo che
4399 accede alla stessa risorsa quando ancora non tutti i passi sono stati
4402 Dato che in un sistema multitasking ogni processo può essere interrotto in
4403 qualunque momento per farne subentrare un altro in esecuzione, niente può
4404 assicurare un preciso ordine di esecuzione fra processi diversi o che una
4405 sezione di un programma possa essere eseguita senza interruzioni da parte di
4406 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
4407 difficili da tracciare, in quanto nella maggior parte dei casi tutto
4408 funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
4410 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
4411 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
4412 gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
4413 \textit{race condition} si hanno quando diversi processi accedono allo stesso
4414 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
4417 \index{sezione~critica|(}
4419 In questi casi, se non si dispone della possibilità di eseguire atomicamente
4420 le operazioni necessarie, occorre che quelle parti di codice in cui si
4421 compiono le operazioni sulle risorse condivise, quelle che in genere vengono
4422 denominate ``\textsl{sezioni critiche}'' del programma, siano opportunamente
4423 protette da meccanismi di sincronizzazione (vedremo alcune problematiche di
4424 questo tipo in cap.~\ref{cha:IPC}).
4426 \index{sezione~critica|)}
4428 Nel caso dei \textit{thread} invece la situazione è molto più delicata e
4429 sostanzialmente qualunque accesso in memoria (a buffer, variabili o altro) può
4430 essere soggetto a \textit{race condition} dato potrebbe essere interrotto in
4431 qualunque momento da un altro \textit{thread}. In tal caso occorre pianificare
4432 con estrema attenzione l'uso delle variabili ed utilizzare i vari meccanismi
4433 di sincronizzazione che anche in questo caso sono disponibili (torneremo su
4434 queste problematiche di questo tipo in cap.~\ref{sez:thread_xxx})
4438 Un caso particolare di \textit{race condition} sono poi i cosiddetti
4439 \textit{deadlock} (traducibile in \textsl{condizione di stallo}), che
4440 particolarmente gravi in quanto comportano spesso il blocco completo di un
4441 servizio, e non il fallimento di una singola operazione. Per definizione un
4442 \textit{deadlock} è una situazione in cui due o più processi non sono più in
4443 grado di proseguire perché ciascuno aspetta il risultato di una operazione che
4444 dovrebbe essere eseguita dall'altro.
4446 L'esempio tipico di una situazione che può condurre ad un
4447 \textit{deadlock} è quello in cui un flag di
4448 ``\textsl{occupazione}'' viene rilasciato da un evento asincrono (come un
4449 segnale o un altro processo) fra il momento in cui lo si è controllato
4450 (trovandolo occupato) e la successiva operazione di attesa per lo sblocco. In
4451 questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
4452 accorgessimo proprio fra il controllo e la messa in attesa, quest'ultima
4453 diventerà perpetua (da cui il nome di \textit{deadlock}).
4455 In tutti questi casi è di fondamentale importanza il concetto di atomicità
4456 visto in sez.~\ref{sec:proc_atom_oper}; questi problemi infatti possono essere
4457 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
4458 eseguire in maniera atomica le operazioni necessarie.
4460 \itindend{race~condition}
4464 \subsection{Le funzioni rientranti}
4465 \label{sec:proc_reentrant}
4467 \index{funzioni!rientranti|(}
4469 Si dice \textsl{rientrante} una funzione che può essere interrotta in
4470 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
4471 un altro \textit{thread} di esecuzione senza che questo comporti nessun
4472 problema nell'esecuzione della stessa. La problematica è comune nella
4473 programmazione \textit{multi-thread}, ma si hanno gli stessi problemi quando
4474 si vogliono chiamare delle funzioni all'interno dei gestori dei segnali.
4476 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
4477 queste infatti vengono allocate nello \textit{stack}, ed un'altra invocazione
4478 non fa altro che allocarne un'altra copia. Una funzione può non essere
4479 rientrante quando opera su memoria che non è nello \textit{stack}. Ad esempio
4480 una funzione non è mai rientrante se usa una variabile globale o statica.
4482 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
4483 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
4484 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
4485 esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
4486 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
4487 Allo stesso modo una funzione può non essere rientrante se usa e modifica un
4488 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
4489 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
4490 parte del programmatore.
4492 In genere le funzioni di libreria non sono rientranti, molte di esse ad
4493 esempio utilizzano variabili statiche, la \acr{glibc} però mette a
4494 disposizione due macro di compilatore, \macro{\_REENTRANT} e
4495 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
4496 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
4497 \code{\_r} al nome della versione normale.
4499 \index{funzioni!rientranti|)}
4502 % LocalWords: multitasking like VMS child process identifier pid sez shell fig
4503 % LocalWords: parent kernel init pstree keventd kswapd table struct linux call
4504 % LocalWords: nell'header scheduler system interrupt timer HZ asm Hertz clock
4505 % LocalWords: l'alpha tick fork wait waitpid exit exec image glibc int pgid ps
4506 % LocalWords: sid thread Ingo Molnar ppid getpid getppid sys unistd LD threads
4507 % LocalWords: void tempnam pathname sibling cap errno EAGAIN ENOMEM context
4508 % LocalWords: stack read only copy write tab client spawn forktest sleep PATH
4509 % LocalWords: source LIBRARY scheduling race condition printf descriptor dup
4510 % LocalWords: close group session tms lock vfork execve BSD stream main abort
4511 % LocalWords: SIGABRT SIGCHLD SIGHUP foreground SIGCONT termination signal ANY
4512 % LocalWords: handler kill EINTR POSIX options WNOHANG ECHILD option WUNTRACED
4513 % LocalWords: dump bits rusage getrusage heap const filename argv envp EACCES
4514 % LocalWords: filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF
4515 % LocalWords: ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR
4516 % LocalWords: ENFILE EMFILE argc execl path execv execle execlp execvp vector
4517 % LocalWords: list environ NULL umask utime cutime ustime fcntl linker Posix
4518 % LocalWords: opendir libc interpreter FreeBSD capabilities mandatory access
4519 % LocalWords: control MAC SELinux security modules LSM superuser uid gid saved
4520 % LocalWords: effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr
4521 % LocalWords: getegid IDS NFS setuid setgid all' logout utmp screen xterm TODO
4522 % LocalWords: setreuid setregid FIXME ruid rgid seteuid setegid setresuid size
4523 % LocalWords: setresgid getresuid getresgid value result argument setfsuid DAC
4524 % LocalWords: setfsgid NGROUPS sysconf getgroups getgrouplist groups ngroups
4525 % LocalWords: setgroups initgroups patch LIDS CHOWN OVERRIDE Discrectionary
4526 % LocalWords: SEARCH chattr sticky NOATIME socket domain immutable append mmap
4527 % LocalWords: broadcast multicast multicasting memory locking mlock mlockall
4528 % LocalWords: shmctl ioperm iopl chroot ptrace accounting swap reboot hangup
4529 % LocalWords: vhangup mknod lease permitted inherited inheritable bounding AND
4530 % LocalWords: capability capget capset header ESRCH undef version obj clear PT
4531 % LocalWords: pag ssize length proc capgetp preemptive cache runnable
4532 % LocalWords: SIGSTOP soft slice nice niceness counter which SC switch side
4533 % LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO COUNT
4534 % LocalWords: yield Robin setscheduler policy param OTHER priority setparam to
4535 % LocalWords: min getparam getscheduler interval robin ENOSYS fifo ping long
4536 % LocalWords: affinity setaffinity unsigned mask cpu NUMA CLR ISSET SETSIZE RR
4537 % LocalWords: getaffinity assembler deadlock REENTRANT SAFE tgz MYPGRP l'OR rr
4538 % LocalWords: WIFEXITED WEXITSTATUS WIFSIGNALED WTERMSIG WCOREDUMP WIFSTOPPED
4539 % LocalWords: WSTOPSIG opt char INTERP arg SIG IGN DFL mascheck grp FOWNER RAW
4540 % LocalWords: FSETID SETPCAP BIND SERVICE ADMIN PACKET IPC OWNER MODULE RAWIO
4541 % LocalWords: PACCT RESOURCE TTY CONFIG SETFCAP hdrp datap libcap lcap text tp
4542 % LocalWords: get ncap caps CapInh CapPrm fffffeff CapEff getcap STAT dall'I
4543 % LocalWords: inc PRIO SUSv PRGR prio SysV SunOS Ultrix sched timespec len sig
4544 % LocalWords: cpusetsize cpuset atomic tickless redirezione WCONTINUED stopped
4545 % LocalWords: waitid NOCLDSTOP ENOCHLD WIFCONTINUED ifdef endif idtype siginfo
4546 % LocalWords: infop ALL WEXITED WSTOPPED WNOWAIT signo CLD EXITED KILLED page
4547 % LocalWords: CONTINUED sources forking Spawned successfully executing exiting
4548 % LocalWords: next cat for COMMAND pts bash defunct TRAPPED DUMPED PR effects
4549 % LocalWords: SIGKILL static RLIMIT preemption PREEMPT VOLUNTARY IDLE RTPRIO
4550 % LocalWords: completely fair compat uniform CFQ queuing elevator dev cfq RT
4551 % LocalWords: documentation block syscall ioprio IPRIO CLASS class best effort
4552 % LocalWords: refresh semop dnotify MADV DONTFORK prctl WCLONE WALL big mount
4553 % LocalWords: WNOTHREAD DUMPABLE KEEPCAPS IRIX CAPBSET endianness endian flags
4554 % LocalWords: little PPC PowerPC FPEMU NOPRINT SIGFPE FPEXC point FP SW malloc
4555 % LocalWords: exception EXC ENABLE OVF overflow UND underflow RES INV DISABLED
4556 % LocalWords: NONRECOV ASYNC KEEP securebits NAME NUL PDEATHSIG SECCOMP VM FS
4557 % LocalWords: secure computing sigreturn TIMING STATISTICAL TSC MCE conditions
4558 % LocalWords: timestamp Stamp SIGSEGV UNALIGN SIGBUS MCEERR AO failure early
4559 % LocalWords: namespace vsyscall SETTID FILES NEWIPC NEWNET NEWNS NEWPID ptid
4560 % LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID panic
4561 % LocalWords: loader EISDIR SIGTRAP uninterrutible killable EQUAL sizeof XOR
4562 % LocalWords: destset srcset ALLOC num cpus setsize emacs pager getty TID
4563 % LocalWords: reaper SUBREAPER Library futex
4565 %%% Local Variables:
4567 %%% TeX-master: "gapil"