%% prochand.tex
%%
-%% Copyright (C) 2000-2018 by Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2019 by Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
della terminazione dei processi, della gestione dei loro attributi e
privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
finale introdurremo alcune problematiche generiche della programmazione in
-ambiente multitasking.
+ambiente \textit{multitasking}.
\section{Le funzioni di base della gestione dei processi}
\func{fork} viene implementata tramite \func{clone}, cosa che consente una
migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
centrale tutte le volte che si devono scrivere programmi che usano il
-multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
- \textit{thread}\unavref{ che tratteremo al cap.~\ref{cha:threads}}, è in
- parte minore, ma \func{fork} resta comunque la funzione principale per la
- creazione di processi.} Il prototipo di \funcd{fork} è:
+\textit{multitasking}.\footnote{oggi questa rilevanza, con la diffusione
+ dell'uso dei \textit{thread}\unavref{ che tratteremo al
+ cap.~\ref{cha:threads}}, è in parte minore, ma \func{fork} resta comunque
+ la funzione principale per la creazione di processi.} Il prototipo di
+\funcd{fork} è:
\begin{funcproto}{
\fhead{unistd.h}
duplicare nei processi figli tutti i \textit{file descriptor} (vedi
sez.~\ref{sec:file_fd}) dei file aperti nel processo padre (allo stesso modo
in cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}). Ciò
-fa si che padre e figli condividano le stesse voci della \textit{file table}
+fa sì che padre e figli condividano le stesse voci della \textit{file table}
(tratteremo in dettaglio questi termini in sez.~\ref{sec:file_fd} e
sez.~\ref{sec:file_shared_access}) fra le quali c'è anche la posizione
corrente nel file.
comune dopo l'esecuzione di una \func{fork} è la seguente:
\begin{itemize*}
\item i file aperti e gli eventuali flag di \textit{close-on-exec} impostati
- (vedi sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl_ioctl});
+ (vedi sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_shared_access});
\item gli identificatori per il controllo di accesso: l'\textsl{user-ID
reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
\textsl{group-ID effettivo} ed i \textsl{group-ID supplementari} (vedi
\subsection{Le funzioni di attesa e ricezione degli stati di uscita}
\label{sec:proc_wait}
-Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
-consiste nella creazione di programmi di tipo server, in cui un processo
-principale attende le richieste che vengono poi soddisfatte da una serie di
-processi figli.
+Uno degli usi più comuni delle capacità \textit{multitasking} di un sistema
+unix-like consiste nella creazione di programmi di tipo server, in cui un
+processo principale attende le richieste che vengono poi soddisfatte da una
+serie di processi figli.
Si è già sottolineato al paragrafo precedente come in questo caso diventi
necessario gestire esplicitamente la conclusione dei figli onde evitare di
\end{itemize*}
\itindbeg{close-on-exec}
-
La gestione dei file aperti nel passaggio al nuovo programma lanciato con
-\func{exec} dipende dal valore che ha il flag di \textit{close-on-exec} (vedi
-sez.~\ref{sec:file_fcntl_ioctl}) per ciascun \textit{file descriptor}. I file
-per cui è impostato vengono chiusi, tutti gli altri file restano
+\func{exec} dipende dal valore che ha il flag di \textit{close-on-exec} per
+ciascun \textit{file descriptor} (vedi sez.~\ref{sec:file_shared_access}). I
+file per cui è impostato vengono chiusi, tutti gli altri file restano
aperti. Questo significa che il comportamento predefinito è che i file restano
-aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
-\func{fcntl} che imposti il suddetto flag. Per le directory, lo standard
-POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere
-questo è fatto dalla funzione \func{opendir} (vedi
+aperti attraverso una \func{exec}, a meno di non aver impostato esplicitamente
+(in apertura o con \func{fnctl}) il suddetto flag. Per le directory, lo
+standard POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec},
+in genere questo è fatto dalla funzione \func{opendir} (vedi
sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
\textit{close-on-exec} sulle directory che apre, in maniera trasparente
all'utente.
-
\itindend{close-on-exec}
Il comportamento della funzione in relazione agli identificatori relativi al
\begin{errlist}
\item[\errcode{EAGAIN}] (solo per \func{setuid}) la chiamata cambierebbe
l'\ids{UID} reale ma il kernel non dispone temporaneamente delle risorse per
- farlo, oppure, per i kernel precendenti il 3.1, il cambiamento
+ farlo, oppure, per i kernel precedenti il 3.1, il cambiamento
dell'\ids{UID} reale farebbe superare il limite per il numero dei processi
\const{RLIMIT\_NPROC} (vedi sez.~\ref{sec:sys_resource_limit}).
\item[\errcode{EINVAL}] il valore di dell'argomento non è valido per il
L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
l'\ids{UID} effettivo è zero (cioè è quello dell'amministratore di sistema o
-il processo ha la la capacità \const{CAP\_SETUID}) allora tutti gli
+il processo ha la capacità \const{CAP\_SETUID}) allora tutti gli
identificatori (\textit{real}, \textit{effective} e \textit{saved}) vengono
impostati al valore specificato da \param{uid}, altrimenti viene impostato
solo l'\ids{UID} effettivo, e soltanto se il valore specificato corrisponde o
essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
cui non esiste un meccanismo che sia valido per tutti gli usi.
-La caratteristica specifica di un sistema multitasking come Linux è quella del
-cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
+La caratteristica specifica di un sistema \textit{multitasking} come Linux è
+quella del cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
multitasking}: questo significa che al contrario di altri sistemi (che usano
invece il cosiddetto \itindex{cooperative~multitasking} \textit{cooperative
multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
}
\end{funcbox}}
-Le prime tre macro richiedono due insiemi di partenza, \param{srcset1}
-e \param{srcset2} e forniscono in un terzo insieme \param{destset} (che può
+Le prime tre macro richiedono due insiemi di partenza, \param{srcset1} e
+\param{srcset2} e forniscono in un terzo insieme \param{destset} (che può
essere anche lo stesso di uno dei precedenti) il risultato della rispettiva
operazione logica sui contenuti degli stessi. In sostanza con \macro{CPU\_AND}
si otterrà come risultato l'insieme che contiene le CPU presenti in entrambi
gli insiemi di partenza, con \macro{CPU\_OR} l'insieme che contiene le CPU
presenti in uno qualunque dei due insiemi di partenza, e con \macro{CPU\_XOR}
-l'insieme che contiene le CPU presenti presenti in uno solo dei due insiemi di
+l'insieme che contiene le CPU presenti in uno solo dei due insiemi di
partenza. Infine \macro{CPU\_EQUAL} confronta due insiemi ed è l'unica che
-restituisce un intero, da usare come valore logico che indica se sono
-identici o meno.
+restituisce un intero, da usare come valore logico che indica se sono identici
+o meno.
Inoltre, sempre a partire dalla versione 2.7 della \acr{glibc}, è stata
introdotta la possibilità di una allocazione dinamica degli insiemi di
%TODO verificare http://lwn.net/Articles/355987/
-\section{Funzioni di gestione avanzata}
-\label{sec:proc_advanced_control}
-
-Nelle precedenti sezioni si sono trattate la gran parte delle funzioni che
-attengono alla gestione ordinaria dei processi e delle loro proprietà più
-comuni. Tratteremo qui alcune \textit{system call} dedicate alla gestione di
-funzionalità dei processi molto specifiche ed avanzate, il cui uso è in genere
-piuttosto ridotto. Trattandosi di problematiche abbastanza complesse, che
-spesso presuppongono la conoscenza di altri argomenti trattati nel seguito
-della guida, si può saltare questa sezione in una prima lettura, tornando su
-di essa in un secondo tempo.
-
-
-\subsection{La funzione \func{prctl}}
-\label{sec:process_prctl}
-
-Benché la gestione ordinaria possa essere effettuata attraverso le funzioni
-che abbiamo già esaminato nelle sezioni precedenti, esistono una serie di
-proprietà e caratteristiche particolari dei processi non coperte da esse, per
-la cui gestione è stata predisposta una apposita \textit{system call} che
-fornisce una interfaccia generica per tutte le operazioni specialistiche. La
-funzione di sistema è \funcd{prctl} ed il suo prototipo è:\footnote{la
- funzione non è standardizzata ed è specifica di Linux, anche se ne esiste
- una analoga in IRIX; è stata introdotta con il kernel 2.1.57.}
-
-\begin{funcproto}{
-\fhead{sys/prctl.h}
-\fdecl{int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned
- long arg4, \\
-\phantom{int prctl(}unsigned long arg5)}
-\fdesc{Esegue una operazione speciale sul processo corrente.}
-}
-
-{La funzione ritorna $0$ o un valore positivo dipendente dall'operazione in
- caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà
- valori diversi a seconda del tipo di operazione richiesta, sono possibili:
- \errval{EACCESS}, \errval{EBADF}, \errval{EBUSY}, \errval{EFAULT},
- \errval{EINVAL}, \errval{ENXIO}, \errval{EOPNOTSUPP} o \errval{EPERM}.}
-\end{funcproto}
-
-La funzione ritorna in caso di successo un valore nullo o positivo, e $-1$ in
-caso di errore. Il significato degli argomenti della funzione successivi al
-primo, il valore di ritorno in caso di successo, il tipo di errore restituito
-in \var{errno} dipendono dall'operazione eseguita, indicata tramite il primo
-argomento, \param{option}. Questo è un valore intero che identifica
-l'operazione, e deve essere specificato con l'uso di una delle costanti
-predefinite del seguente elenco.\footnote{l'elenco potrebbe non risultare
- aggiornato, in quanto nuove operazioni vengono aggiunte nello sviluppo del
- kernel.} Tratteremo esplicitamente per ciascuna di esse il significato del
-il valore di ritorno in caso di successo, ma solo quando non corrisponde
-all'ordinario valore nullo (dato per implicito).
-
-%TODO: trattare PR_CAP_AMBIENT, dal 4.3
-%TODO: trattare PR_CAP_FP_*, dal 4.0, solo per MIPS
-%TODO: trattare PR_MPX_*_MANAGEMENT, dal 3.19
-%TODO: trattare PR_*NO_NEW_PRIVS, dal 3.5
-%TODO: trattare PR_SET_PTRACER, dal 3.4
-
-\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
-\item[\constd{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
- \textit{capability} (vedi sez.~\ref{sec:proc_capabilities}). La funzione
- ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una
- delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel
- \textit{capabilities bounding set} del processo e zero altrimenti,
- se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}.
- Introdotta a partire dal kernel 2.6.25.
-
-\item[\constd{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
- \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e
- da tutti i suoi discendenti. La funzione cancella la capacità specificata
- nell'argomento \param{arg2} con una delle costanti di
- tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del
- processo. L'operazione richiede i privilegi di amministratore (la capacità
- \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
- \errcode{EPERM}; se il valore di \param{arg2} non è valido o se il supporto
- per le \textit{file capabilities} non è stato compilato nel kernel la
- chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal
- kernel 2.6.25.
-
-\item[\constd{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
- terminazione di un processo a causa di un segnale per il quale è prevista la
- generazione di un file di \textit{core dump} (vedi
- sez.~\ref{sec:sig_standard}) lo genera effettivamente. In genere questo flag
- viene attivato automaticamente, ma per evitare problemi di sicurezza (la
- generazione di un file da parte di processi privilegiati può essere usata
- per sovrascriverne altri) viene cancellato quando si mette in esecuzione un
- programma con i bit \acr{suid} e \acr{sgid} attivi (vedi
- sez.~\ref{sec:file_special_perm}) o con l'uso delle funzioni per la modifica
- degli \ids{UID} dei processi (vedi sez.~\ref{sec:proc_setuid}).
-
- L'operazione è stata introdotta a partire dal kernel 2.3.20, fino al kernel
- 2.6.12 e per i kernel successivi al 2.6.17 era possibile usare solo un
- valore 0 (espresso anche come \constd{SUID\_DUMP\_DISABLE}) di \param{arg2}
- per disattivare il flag ed un valore 1 (espresso anche come
- \constd{SUID\_DUMP\_USER}) per attivarlo. Nei kernel dal 2.6.13 al 2.6.17 è
- stato supportato anche il valore 2, che causava la generazione di un
- \textit{core dump} leggibile solo dall'amministratore, ma questa
- funzionalità è stata rimossa per motivi di sicurezza, in quanto consentiva
- ad un utente normale di creare un file di \textit{core dump} appartenente
- all'amministratore in directory dove l'utente avrebbe avuto permessi di
- accesso. Specificando un valore diverso da 0 o 1 si ottiene un errore di
- \errval{EINVAL}.
-
-\item[\constd{PR\_GET\_DUMPABLE}] Ottiene come valore di ritorno della funzione
- lo stato corrente del flag che controlla la effettiva generazione dei
- \textit{core dump}. Introdotta a partire dal kernel 2.3.20.
-
-\item[\constd{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
- chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
- sono: \constd{PR\_ENDIAN\_BIG} (\textit{big endian}),
- \constd{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
- \constd{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
- PowerPC). Introdotta a partire dal kernel 2.6.18, solo per architettura
- PowerPC.
-
-\item[\constd{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianness} del
- processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
- essere passata come di tipo ``\ctyp{int *}''. Introdotta a partire dal
- kernel 2.6.18, solo su PowerPC.
-
-\item[\constd{PR\_SET\_FPEMU}] Imposta i bit di controllo per l'emulazione
- della virgola mobile su architettura ia64, secondo il valore
- di \param{arg2}, si deve passare \constd{PR\_FPEMU\_NOPRINT} per emulare in
- maniera trasparente l'accesso alle operazioni in virgola mobile, o
- \constd{PR\_FPEMU\_SIGFPE} per non emularle ed inviare il segnale
- \signal{SIGFPE} (vedi sez.~\ref{sec:sig_prog_error}). Introdotta a partire
- dal kernel 2.4.18, solo su architettura ia64.
-
-\item[\constd{PR\_GET\_FPEMU}] Ottiene il valore dei flag di controllo
- dell'emulazione della virgola mobile, salvato all'indirizzo puntato
- da \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
- partire dal kernel 2.4.18, solo su architettura ia64.
-
-\item[\constd{PR\_SET\_FPEXC}] Imposta la modalità delle eccezioni in virgola
- mobile (\textit{floating-point exception mode}) al valore di \param{arg2}.
- I valori possibili sono:
- \begin{itemize*}
- \item \constd{PR\_FP\_EXC\_SW\_ENABLE} per usare FPEXC per le eccezioni,
- \item \constd{PR\_FP\_EXC\_DIV} per la divisione per zero in virgola mobile,
- \item \constd{PR\_FP\_EXC\_OVF} per gli overflow,
- \item \constd{PR\_FP\_EXC\_UND} per gli underflow,
- \item \constd{PR\_FP\_EXC\_RES} per risultati non esatti,
- \item \constd{PR\_FP\_EXC\_INV} per operazioni invalide,
- \item \constd{PR\_FP\_EXC\_DISABLED} per disabilitare le eccezioni,
- \item \constd{PR\_FP\_EXC\_NONRECOV} per usare la modalità di eccezione
- asincrona non recuperabile,
- \item \constd{PR\_FP\_EXC\_ASYNC} per usare la modalità di eccezione
- asincrona recuperabile,
- \item \constd{PR\_FP\_EXC\_PRECISE} per la modalità precisa di
- eccezione.\footnote{trattasi di gestione specialistica della gestione
- delle eccezioni dei calcoli in virgola mobile che, i cui dettagli al
- momento vanno al di là dello scopo di questo testo.}
- \end{itemize*}
-Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
-
-\item[\constd{PR\_GET\_FPEXC}] Ottiene il valore della modalità delle eccezioni
- delle operazioni in virgola mobile, salvata all'indirizzo
- puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta
- a partire dal kernel 2.4.21, solo su PowerPC.
-
-\item[\constd{PR\_SET\_KEEPCAPS}] Consente di controllare quali
- \textit{capabilities} vengono cancellate quando si esegue un cambiamento di
- \ids{UID} del processo (per i dettagli si veda
- sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
- pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
- per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
- mantenute, questo valore viene sempre cancellato attraverso una \func{exec}.
- L'uso di questo flag è stato sostituito, a partire dal kernel 2.6.26, dal
- flag \const{SECURE\_KEEP\_CAPS} dei \textit{securebits} (vedi
- sez.~\ref{sec:proc_capabilities} e l'uso di \const{PR\_SET\_SECUREBITS} più
- avanti) e si è impostato con essi \const{SECURE\_KEEP\_CAPS\_LOCKED} si
- otterrà un errore di \errval{EPERM}. Introdotta a partire dal kernel
- 2.2.18.
-
-\item[\constd{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
- il valore del flag di controllo delle \textit{capabilities} impostato con
- \const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18.
-
-\item[\constd{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla
- stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}''. Il
- nome può essere lungo al massimo 16 caratteri, e la stringa deve essere
- terminata da NUL se più corta. Introdotta a partire dal kernel 2.6.9.
-
-\item[\constd{PR\_GET\_NAME}] Ottiene il nome del processo chiamante nella
- stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}'';
- si devono allocare per questo almeno 16 byte, e il nome sarà terminato da
- NUL se più corto. Introdotta a partire dal kernel 2.6.9.
-
-\item[\constd{PR\_SET\_PDEATHSIG}] Consente di richiedere l'emissione di un
- segnale, che sarà ricevuto dal processo chiamante, in occorrenza della
- terminazione del proprio processo padre; in sostanza consente di invertire
- il ruolo di \signal{SIGCHLD}. Il valore di \param{arg2} deve indicare il
- numero del segnale, o 0 per disabilitare l'emissione. Il valore viene
- automaticamente cancellato per un processo figlio creato con \func{fork}.
- Introdotta a partire dal kernel 2.1.57.
-
-\item[\constd{PR\_GET\_PDEATHSIG}] Ottiene il valore dell'eventuale segnale
- emesso alla terminazione del padre, salvato all'indirizzo
- puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
- partire dal kernel 2.3.15.
-
-\item[\constd{PR\_SET\_PTRACER}] Imposta un \ids{PID} per il ``\textit{tracer
- process}'' usando \param{arg2}. Una impostazione successiva sovrascrive la
- precedente, ed un valore nullo cancella la disponibilità di un
- ``\textit{tracer process}''. Questa è una funzionalità fornita da
- \textit{``Yama''}, uno specifico \textit{Linux Security Modules}, e serve a
- consentire al processo indicato, quando le restrioni introdotte da questo
- modulo sono attive, di usare \func{ptrace}\unavref{ (vedi
- sez.\ref{sec:process_ptrace})} sul processo chiamante, anche se quello
- indicato non ne è un progenitore. Il valore \constd{PR\_SET\_PTRACER\_ANY}
- consente a tutti i processi l'uso di \func{ptrace}. L'uso si \textit{Yama}
- attiene alla gestione della sicurezza dei processi, e consente di introdurre
- una restrizione all'uso di \func{ptrace}, che è spesso sorgente di
- compromissioni. Si tratta di un uso specialistico che va al di là dello
- scopo di queste dispense, per i dettagli si consulti la documentazione su
- \textit{Yama} nei sorgenti del kernel. Introdotta a partire dal kernel 3.4.
-
-\itindbeg{secure~computing~mode}
-\item[\constd{PR\_SET\_SECCOMP}] Imposta il cosiddetto \textit{secure computing
- mode} per il processo corrente. Prevede come unica possibilità
- che \param{arg2} sia impostato ad 1. Una volta abilitato il \textit{secure
- computing mode} il processo potrà utilizzare soltanto un insieme
- estremamente limitato di \textit{system call}: \func{read}, \func{write},
- \func{\_exit} e \funcm{sigreturn}. Ogni altra \textit{system call} porterà
- all'emissione di un \signal{SIGKILL} (vedi sez.~\ref{sec:sig_termination}).
- Il \textit{secure computing mode} è stato ideato per fornire un supporto per
- l'esecuzione di codice esterno non fidato e non verificabile a scopo di
- calcolo;\footnote{lo scopo è quello di poter vendere la capacità di calcolo
- della proprio macchina ad un qualche servizio di calcolo distribuito senza
- comprometterne la sicurezza eseguendo codice non sotto il proprio
- controllo.} in genere i dati vengono letti o scritti grazie ad un socket o
- una \textit{pipe}, e per evitare problemi di sicurezza non sono possibili
- altre operazioni se non quelle citate. Introdotta a partire dal kernel
- 2.6.23, disponibile solo se si è abilitato il supporto nel kernel con
- \texttt{CONFIG\_SECCOMP}.
-
-% TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
-% terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
-% Documentation/prctl/seccomp_filter.txt
-% vedi anche http://lwn.net/Articles/600250/
-
-% TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
-% * Documentation/prctl/seccomp_filter.txt
-% * http://lwn.net/Articles/475043/
-
-% TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
-% vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
-
-\item[\constd{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
- lo stato corrente del \textit{secure computing mode}, al momento attuale la
- funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
- che la chiamata di questa funzione in \textit{secure computing mode}
- comporterebbe l'emissione di \signal{SIGKILL}, è stata comunque definita per
- eventuali estensioni future. Introdotta a partire dal kernel 2.6.23.
-\itindend{secure~computing~mode}
-
-\item[\constd{PR\_SET\_SECUREBITS}] Imposta i \textit{securebits} per il
- processo chiamante al valore indicato da \param{arg2}; per i dettagli sul
- significato dei \textit{securebits} si veda
- sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
- tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione
- richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}),
- altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a
- partire dal kernel 2.6.26.
-
-\item[\constd{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
- funzione l'impostazione corrente per i \textit{securebits}. Introdotta a
- partire dal kernel 2.6.26.
-
-\item[\constd{PR\_SET\_TIMING}] Imposta il metodo di temporizzazione del
- processo da indicare con il valore di \param{arg2}, attualmente i valori
- possibili sono due, con \constd{PR\_TIMING\_STATISTICAL} si usa il metodo
- statistico tradizionale, con \constd{PR\_TIMING\_TIMESTAMP} il più accurato
- basato su dei \textit{timestamp}, quest'ultimo però non è ancora
- implementato ed il suo uso comporta la restituzione di un errore di
- \errval{EINVAL}. Introdotta a partire dal kernel 2.6.0-test4.
-
-\item[\constd{PR\_GET\_TIMING}] Ottiene come valore di ritorno della funzione
- il metodo di temporizzazione del processo attualmente in uso (uno dei due
- valori citati per \const{PR\_SET\_TIMING}). Introdotta a partire dal kernel
- 2.6.0-test4.
-
-\item[\constd{PR\_SET\_TSC}] Imposta il flag che indica se il processo
- chiamante può leggere il registro di processore contenente il contatore dei
- \textit{timestamp} (TSC, o \textit{Time Stamp Counter}) da indicare con il
- valore di \param{arg2}. Si deve specificare \constd{PR\_TSC\_ENABLE} per
- abilitare la lettura o \constd{PR\_TSC\_SIGSEGV} per disabilitarla con la
- generazione di un segnale di \signal{SIGSEGV} (vedi
- sez.~\ref{sec:sig_prog_error}). La lettura viene automaticamente
- disabilitata se si attiva il \textit{secure computing mode} (vedi
- \const{PR\_SET\_SECCOMP}). Introdotta a partire dal kernel
- 2.6.26, solo su x86.
-
-\item[\constd{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
- lettura del contattore dei \textit{timestamp}, salvato all'indirizzo
- puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
- partire dal kernel 2.6.26, solo su x86.
-% articoli sul TSC e relativi problemi: http://lwn.net/Articles/209101/,
-% http://blog.cr0.org/2009/05/time-stamp-counter-disabling-oddities.html,
-% http://en.wikipedia.org/wiki/Time_Stamp_Counter
-
-\item[\constd{PR\_SET\_UNALIGN}] Imposta la modalità di controllo per l'accesso
- a indirizzi di memoria non allineati, che in varie architetture risultano
- illegali, da indicare con il valore di \param{arg2}. Si deve specificare il
- valore \constd{PR\_UNALIGN\_NOPRINT} per ignorare gli accessi non allineati,
- ed il valore \constd{PR\_UNALIGN\_SIGBUS} per generare un segnale di
- \signal{SIGBUS} (vedi sez.~\ref{sec:sig_prog_error}) in caso di accesso non
- allineato. Introdotta con diverse versioni su diverse architetture.
-
-\item[\const{PR\_GET\_UNALIGN}] Ottiene il valore della modalità di controllo
- per l'accesso a indirizzi di memoria non allineati, salvato all'indirizzo
- puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta con
- diverse versioni su diverse architetture.
-\item[\const{PR\_MCE\_KILL}] Imposta la politica di gestione degli errori
- dovuti a corruzione della memoria per problemi hardware. Questo tipo di
- errori vengono riportati dall'hardware di controllo della RAM e vengono
- gestiti dal kernel,\footnote{la funzionalità è disponibile solo sulle
- piattaforme più avanzate che hanno il supporto hardware per questo tipo di
- controlli.} ma devono essere opportunamente riportati ai processi che
- usano quella parte di RAM che presenta errori; nel caso specifico questo
- avviene attraverso l'emissione di un segnale di \signal{SIGBUS} (vedi
- sez.~\ref{sec:sig_prog_error}).\footnote{in particolare viene anche
- impostato il valore di \var{si\_code} in \struct{siginfo\_t} a
- \const{BUS\_MCEERR\_AO}; per il significato di tutto questo si faccia
- riferimento alla trattazione di sez.~\ref{sec:sig_sigaction}.}
-
- Il comportamento di default prevede che per tutti i processi si applichi la
- politica generale di sistema definita nel file
- \sysctlfiled{vm/memory\_failure\_early\_kill}, ma specificando
- per \param{arg2} il valore \constd{PR\_MCE\_KILL\_SET} è possibile impostare
- con il contenuto di \param{arg3} una politica specifica del processo
- chiamante. Si può tornare alla politica di default del sistema utilizzando
- invece per \param{arg2} il valore \constd{PR\_MCE\_KILL\_CLEAR}. In tutti i
- casi, per compatibilità con eventuali estensioni future, tutti i valori
- degli argomenti non utilizzati devono essere esplicitamente posti a zero,
- pena il fallimento della chiamata con un errore di \errval{EINVAL}.
-
- In caso di impostazione di una politica specifica del processo con
- \const{PR\_MCE\_KILL\_SET} i valori di \param{arg3} possono essere soltanto
- due, che corrispondono anche al valore che si trova nell'impostazione
- generale di sistema di \texttt{memory\_failure\_early\_kill}, con
- \constd{PR\_MCE\_KILL\_EARLY} si richiede l'emissione immediata di
- \signal{SIGBUS} non appena viene rilevato un errore, mentre con
- \constd{PR\_MCE\_KILL\_LATE} il segnale verrà inviato solo quando il processo
- tenterà un accesso alla memoria corrotta. Questi due valori corrispondono
- rispettivamente ai valori 1 e 0 di
- \texttt{memory\_failure\_early\_kill}.\footnote{in sostanza nel primo caso
- viene immediatamente inviato il segnale a tutti i processi che hanno la
- memoria corrotta mappata all'interno del loro spazio degli indirizzi, nel
- secondo caso prima la pagina di memoria viene tolta dallo spazio degli
- indirizzi di ciascun processo, mentre il segnale viene inviato solo quei
- processi che tentano di accedervi.} Si può usare per \param{arg3} anche un
- terzo valore, \constd{PR\_MCE\_KILL\_DEFAULT}, che corrisponde a impostare
- per il processo la politica di default.\footnote{si presume la politica di
- default corrente, in modo da non essere influenzati da un eventuale
- successivo cambiamento della stessa.} Introdotta a partire dal kernel
- 2.6.32.
-\item[\constd{PR\_MCE\_KILL\_GET}] Ottiene come valore di ritorno della
- funzione la politica di gestione degli errori dovuti a corruzione della
- memoria. Tutti gli argomenti non utilizzati (al momento tutti) devono essere
- nulli pena la ricezione di un errore di \errval{EINVAL}. Introdotta a
- partire dal kernel 2.6.32.
-\itindbeg{child~reaper}
-\item[\constd{PR\_SET\_CHILD\_SUBREAPER}] Se \param{arg2} è diverso da zero
- imposta l'attributo di \textit{child reaper} per il processo, se nullo lo
- cancella. Lo stato di \textit{child reaper} è una funzionalità, introdotta
- con il kernel 3.4, che consente di far svolgere al processo che ha questo
- attributo il ruolo di ``\textsl{genitore adottivo}'' per tutti i processi
- suoi ``\textsl{discendenti}'' che diventano orfani, in questo modo il
- processo potrà ricevere gli stati di terminazione alla loro uscita,
- sostituendo in questo ruolo \cmd{init} (si ricordi quanto illustrato in
- sez.~\ref{sec:proc_termination}). Il meccanismo è stato introdotto ad uso
- dei programmi di gestione dei servizi, per consentire loro di ricevere gli
- stati di terminazione di tutti i processi che lanciano, anche se questi
- eseguono una doppia \func{fork}; nel comportamento ordinario infatti questi
- verrebbero adottati da \cmd{init} ed il programma che li ha lanciati non
- sarebbe più in grado di riceverne lo stato di terminazione. Se un processo
- con lo stato di \textit{child reaper} termina prima dei suoi discendenti,
- svolgerà questo ruolo il più prossimo antenato ad avere lo stato di
- \textit{child reaper},
-\item[\constd{PR\_GET\_CHILD\_SUBREAPER}] Ottiene l'impostazione relativa allo
- lo stato di \textit{child reaper} del processo chiamante, salvata come
- \textit{value result} all'indirizzo puntato da \param{arg2} (da indicare
- come di tipo \code{int *}). Il valore viene letto come valore logico, se
- diverso da 0 lo stato di \textit{child reaper} è attivo altrimenti è
- disattivo. Introdotta a partire dal kernel 3.4.
-\itindend{child~reaper}
-
-
-% TODO documentare PR_MPX_INIT e PR_MPX_RELEASE, vedi
-% http://lwn.net/Articles/582712/
-
-% TODO documentare PR_SET_MM_MAP aggiunta con il kernel 3.18, per impostare i
-% parametri di base del layout dello spazio di indirizzi di un processo (area
-% codice e dati, stack, brack pointer ecc. vedi
-% http://git.kernel.org/linus/f606b77f1a9e362451aca8f81d8f36a3a112139e
-
-% TODO documentare ARCH_SET_CPUID e ARCH_GET_CPUID, introdotte con il kernel
-% 4.12, vedi https://lwn.net/Articles/721182/
-
-
-\label{sec:prctl_operation}
-\end{basedescript}
-
-
-\subsection{La \textit{system call} \func{clone}}
-\label{sec:process_clone}
-
-La funzione tradizionale con cui creare un nuovo processo in un sistema
-Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con
-l'introduzione del supporto del kernel per i \textit{thread} (vedi
-cap.~\ref{cha:threads}), si è avuta la necessità di una interfaccia che
-consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi
-processi, che poi è stata utilizzata anche per fornire supporto per le
-tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container}).
-
-Per questo l'interfaccia per la creazione di un nuovo processo è stata
-delegata ad una nuova \textit{system call}, \funcm{sys\_clone}, che consente
-di reimplementare anche la tradizionale \func{fork}. In realtà in questo caso
-più che di nuovi processi si può parlare della creazioni di nuovi
-``\textit{task}'' del kernel che possono assumere la veste sia di un processo
-classico isolato dagli altri come quelli trattati finora, che di un
-\textit{thread} in cui la memoria viene condivisa fra il processo chiamante ed
-il nuovo processo creato, come quelli che vedremo in
-sez.~\ref{sec:linux_thread}. Per evitare confusione fra \textit{thread} e
-processi ordinari, abbiamo deciso di usare la nomenclatura \textit{task} per
-indicare la unità di esecuzione generica messa a disposizione del kernel che
-\texttt{sys\_clone} permette di creare.
-
-\itindbeg{namespace}
-\itindbeg{container}
-
-Oltre a questo la funzione consente, ad uso delle nuove funzionalità di
-virtualizzazione dei processi, di creare nuovi ``\textit{namespace}'' per una
-serie di proprietà generali (come l'elenco dei \ids{PID}, l'albero dei file, i
-\textit{mount point}, la rete, il sistema di IPC, ecc.). L'uso dei
-``\textit{namespace}'' consente creare gruppi di processi che vedono le
-suddette proprietà in maniera indipendente fra loro. I processi di ciascun
-gruppo vengono così eseguiti come in una sorta di spazio separato da quello
-degli altri gruppi, che costituisce poi quello che viene chiamato un
-\textit{container}.
-
-\itindend{namespace}
-\itindend{container}
-
-La \textit{system call} richiede soltanto due argomenti: il
-primo, \param{flags}, consente di controllare le modalità di creazione del
-nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
-dello \textit{stack} per il nuovo \textit{task}, e deve essere indicato quando
-si intende creare un \textit{thread}. L'esecuzione del programma creato da
-\func{sys\_clone} riprende, come per \func{fork}, da dopo l'esecuzione della
-stessa.
-
-La necessità di avere uno \textit{stack} alternativo c'è solo quando si
-intende creare un \textit{thread}, in tal caso infatti il nuovo \textit{task}
-vede esattamente la stessa memoria del \textit{task}
-``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
- il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
- da essa creato, senza nessuna delle implicazioni che il concetto ha per i
- processi.} e nella sua esecuzione alla prima chiamata di una funzione
-andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi
-quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello
-\textit{stack}).
-
-Per evitare di doversi garantire contro la evidente possibilità di
-\textit{race condition} che questa situazione comporta (vedi
-sez.~\ref{sec:proc_race_cond} per una spiegazione della problematica) è
-necessario che il chiamante allochi preventivamente un'area di memoria. In
-genere lo si fa con una \func{malloc} che allochi un buffer che la funzione
-imposterà come \textit{stack} del nuovo processo, avendo ovviamente cura di
-non utilizzarlo direttamente nel processo chiamante.
-
-In questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
-non si dovranno affrontare problematiche di \textit{race condition}. Si tenga
-presente inoltre che in molte architetture di processore lo \textit{stack}
-cresce verso il basso, pertanto in tal caso non si dovrà specificare
-per \param{child\_stack} il puntatore restituito da \func{malloc}, ma un
-puntatore alla fine del buffer da essa allocato.
-
-Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
-memoria, la \textit{system call}, a differenza della funzione di libreria che
-vedremo a breve, consente anche di passare per \param{child\_stack} il valore
-\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
-processo, questo ottiene un suo nuovo spazio degli indirizzi (è sottinteso
-cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo a breve) ed
-in questo caso si applica la semantica del \textit{copy on write} illustrata
-in sez.~\ref{sec:proc_fork}, per cui le pagine dello \textit{stack} verranno
-automaticamente copiate come le altre e il nuovo processo avrà un suo
-\textit{stack} totalmente indipendente da quello del padre.
-
-Dato che l'uso principale della nuova \textit{system call} è quello relativo
-alla creazione dei \textit{thread}, la \acr{glibc} definisce una funzione di
-libreria con una sintassi diversa, orientata a questo scopo, e la
-\textit{system call} resta accessibile solo se invocata esplicitamente come
-visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
- \textit{system call} non è disponibile la chiamata veloce con
- \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente
-\funcd{clone} ed il suo prototipo è:
-
-\begin{funcproto}{
-\fhead{sched.h}
-\fdecl{int clone(int (*fn)(void *), void *child\_stack, int flags, void *arg,
- ... \\
-\phantom{int clone(}/* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */ )}
-\fdesc{Crea un nuovo processo o \textit{thread}.}
-}
-{La funzione ritorna il \textit{Thread ID} assegnato al nuovo processo in caso
- di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
- valori:
-\begin{errlist}
- \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi.
- \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
- un valore nullo per \param{child\_stack}.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
- \texttt{task\_struct} o per copiare le parti del contesto del chiamante
- necessarie al nuovo \textit{task}.
- \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
- richiesti dai flag indicati.
-\end{errlist}}
-\end{funcproto}
-
-% NOTE: una pagina con la descrizione degli argomenti:
-% * http://www.lindevdoc.org/wiki/Clone
-
-La funzione prende come primo argomento \param{fn} il puntatore alla funzione
-che verrà messa in esecuzione nel nuovo processo, che può avere un unico
-argomento di tipo puntatore a \ctyp{void}, il cui valore viene passato dal
-terzo argomento \param{arg}. Per quanto il precedente prototipo possa
-intimidire nella sua espressione, in realtà l'uso è molto semplice basterà
-definire una qualunque funzione \param{fn} che restituisce un intero ed ha
-come argomento un puntatore a \ctyp{void}, e \code{fn(arg)} sarà eseguita in
-un nuovo processo.
-
-Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn}
-non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore
-di ritorno della funzione (o quello specificato con \func{exit}) verrà
-utilizzato come stato di uscita della funzione. I tre
-argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono
-presenti solo a partire dal kernel 2.6 e sono stati aggiunti come supporto per
-le funzioni di gestione dei \textit{thread} (la \textit{Native Thread Posix
- Library}, vedi sez.~\ref{sec:linux_ntpl}) nella \acr{glibc}, essi vengono
-utilizzati soltanto se si sono specificati rispettivamente i flag
-\const{CLONE\_PARENT\_SETTID}, \const{CLONE\_SETTLS} e
-\const{CLONE\_CHILD\_SETTID}.
-
-La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
-\texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
-al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
-un processo ordinario e non un \textit{thread}.
-
-Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
-nuovo processo da essa creato, è controllato principalmente
-dall'argomento \param{flags}, che deve essere specificato come maschera
-binaria, ottenuta con un OR aritmetico di una delle costanti del seguente
-elenco, che illustra quelle attualmente disponibili:\footnote{si fa
- riferimento al momento della stesura di questa sezione, cioè con il kernel
- 3.2.}
-
-\begin{basedescript}{\desclabelwidth{1.5 cm}\desclabelstyle{\nextlinelabel}}
-
-\item[\constd{CLONE\_CHILD\_CLEARTID}] cancella il valore del \textit{thread
- ID} posto all'indirizzo dato dall'argomento \param{ctid}, eseguendo un
- riattivazione del \textit{futex} (vedi sez.~\ref{sec:xxx_futex}) a
- quell'indirizzo. Questo flag viene utilizzato dalla librerie di gestione dei
- \textit{thread} ed è presente dal kernel 2.5.49.
-
-\item[\constd{CLONE\_CHILD\_SETTID}] scrive il \ids{TID} del \textit{thread}
- figlio all'indirizzo dato dall'argomento \param{ctid}. Questo flag viene
- utilizzato dalla librerie di gestione dei \textit{thread} ed è presente dal
- kernel 2.5.49.
-
-\item[\constd{CLONE\_FILES}] se impostato il nuovo processo condividerà con il
- padre la \textit{file descriptor table} (vedi sez.~\ref{sec:file_fd}),
- questo significa che ogni \textit{file descriptor} aperto da un processo
- verrà visto anche dall'altro e che ogni chiusura o cambiamento dei
- \textit{file descriptor flag} di un \textit{file descriptor} verrà per
- entrambi.
-
- Se non viene impostato il processo figlio eredita una copia della
- \textit{file descriptor table} del padre e vale la semantica classica della
- gestione dei \textit{file descriptor}, che costituisce il comportamento
- ordinario di un sistema unix-like e che illustreremo in dettaglio in
- sez.~\ref{sec:file_shared_access}.
-
-\item[\constd{CLONE\_FS}] se questo flag viene impostato il nuovo processo
- condividerà con il padre le informazioni relative all'albero dei file, ed in
- particolare avrà la stessa radice (vedi sez.~\ref{sec:file_chroot}), la
- stessa directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la stessa
- \textit{umask} (sez.~\ref{sec:file_perm_management}). Una modifica di una
- qualunque di queste caratteristiche in un processo, avrà effetto anche
- sull'altro. Se assente il nuovo processo riceverà una copia delle precedenti
- informazioni, che saranno così indipendenti per i due processi, come avviene
- nel comportamento ordinario di un sistema unix-like.
-
-\item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo il nuovo
- processo condividerà con il padre il contesto dell'I/O, altrimenti, come
- come avviene nel comportamento ordinario con una \func{fork} otterrà un suo
- contesto dell'I/O.
-
- Il contesto dell'I/O viene usato dagli \textit{scheduler} di I/O (visti in
- sez.~\ref{sec:io_priority}) e se questo è lo stesso per diversi processi
- questi vengono trattati come se fossero lo stesso, condividendo il tempo per
- l'accesso al disco, e possono interscambiarsi nell'accesso a disco. L'uso di
- questo flag consente, quando più \textit{thread} eseguono dell'I/O per conto
- dello stesso processo (ad esempio con le funzioni di I/O asincrono di
- sez.~\ref{sec:file_asyncronous_io}), migliori prestazioni.
-
-%TODO : tutti i CLONE_NEW* attengono ai namespace, ed è meglio metterli nella
-%relativa sezione da creare a parte
-
-% \item[\constd{CLONE\_NEWIPC}] è uno dei flag ad uso dei \textit{container},
-% introdotto con il kernel 2.6.19. L'uso di questo flag crea per il nuovo
-% processo un nuovo \textit{namespace} per il sistema di IPC, sia per quello
-% di SysV (vedi sez.~\ref{sec:ipc_sysv}) che, dal kernel 2.6.30, per le code
-% di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); si applica cioè a
-% tutti quegli oggetti che non vegono identificati con un \textit{pathname}
-% sull'albero dei file.
-
-% L'uso di questo flag richiede privilegi di amministratore (più precisamente
-% la capacità \const{CAP\_SYS\_ADMIN}) e non può essere usato in combinazione
-% con \const{CLONE\_SYSVSEM}.
-
-% \item[\constd{CLONE\_NEWNET}]
-% \item[\constd{CLONE\_NEWNS}]
-% \item[\constd{CLONE\_NEWPID}]
-% \item[\constd{CLONE\_NEWUTS}]
-
-
-% TODO trattare CLONE_NEWCGROUP introdotto con il kernel 4.6, vedi
-% http://lwn.net/Articles/680566/
-
-\item[\constd{CLONE\_PARENT}]
-\item[\constd{CLONE\_PARENT\_SETTID}]
-\item[\constd{CLONE\_PID}]
-
-\item[\constd{CLONE\_PTRACE}] se questo flag viene impostato ed il processo
- chiamante viene tracciato (vedi sez.~\ref{sec:process_ptrace}) anche il
- figlio viene tracciato.
-
-\item[\constd{CLONE\_SETTLS}]
-\item[\constd{CLONE\_SIGHAND}]
-\item[\constd{CLONE\_STOPPED}]
-\item[\constd{CLONE\_SYSVSEM}]
-\item[\constd{CLONE\_THREAD}]
-
-\item[\constd{CLONE\_UNTRACED}] se questo flag viene impostato un processo non
- può più forzare \const{CLONE\_PTRACE} su questo processo.
-
-\item[\constd{CLONE\_VFORK}] se questo flag viene impostato il chiamante viene
- fermato fintato che il figlio appena creato non rilascia la sua memoria
- virtuale con una chiamata a \func{exec} o \func{exit}, viene quindi
- replicato il comportamento di \func{vfork}.
-
-\item[\constd{CLONE\_VM}] se questo flag viene impostato il nuovo processo
- condividerà con il padre la stessa memoria virtuale, e le scritture in
- memoria fatte da uno qualunque dei processi saranno visibili dall'altro,
- così come ogni mappatura in memoria (vedi sez.~\ref{sec:file_memory_map}).
-
- Se non viene impostato il processo figlio otterrà una copia dello spazio
- degli indirizzi e si otterrà il comportamento ordinario di un processo di un
- sistema unix-like creato con la funzione \func{fork}.
-\end{basedescript}
-
-
-\subsection{I \textit{namespace} ed i \textit{container}}
-\label{sec:process_namespaces}
-
-
-%TODO sezione separata sui namespace
-
-%TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/
-
-%TODO: trattare la funzione setns e i namespace file descriptors (vedi
-% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0, altre
-% informazioni su setns qui: http://lwn.net/Articles/532748/
-% http://lwn.net/Articles/531498/
-
-
-% TODO trattare le funzioni di protezione della memoria pkey_alloc, pkey_free,
-% pkey_mprotect, introdotte con il kernel 4.8, vedi
-% http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
-
-%TODO trattare kcmp aggiunta con il kernel 3.5, vedi
-% https://lwn.net/Articles/478111/
-
-%\subsection{La funzione \func{ptrace}}
-%\label{sec:process_ptrace}
-
-%Da fare
-
-% TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
-% TODO: trattare PTRACE_O_EXITKILL, aggiunta con il kernel 3.8 (vedi
-% http://lwn.net/Articles/529060/)
-% TODO: trattare PTRACE_GETSIGMASK e PTRACE_SETSIGMASK introdotte con il
-% kernel 3.11
-% TODO: trattare PTRACE_O_SUSPEND_SECCOMP, aggiunta con il kernel 4.3, vedi
-% http://lwn.net/Articles/656675/
-
-%\subsection{La gestione delle operazioni in virgola mobile}
-%\label{sec:process_fenv}
-
-%Da fare.
-
-% TODO eccezioni ed arrotondamenti per la matematica in virgola mobile
-% consultare la manpage di fenv, math_error, fpclassify, matherr, isgreater,
-% isnan, nan, INFINITY
-
-
-%\subsection{L'accesso alle porte di I/O}
-%\label{sec:process_io_port}
-
-%
-% TODO l'I/O sulle porte di I/O
-% consultare le manpage di ioperm, iopl e outb
-% non c'entra nulla qui, va trovato un altro posto (altri meccanismi di I/O in
-% fileintro ?)
-
-%Da fare
-
-
-%\subsection{La gestione di architetture a nodi multipli}
-%\label{sec:process_NUMA}
-
-% TODO trattare i cpuset, che attiene anche a NUMA, e che possono essere usati
-% per associare l'uso di gruppi di processori a gruppi di processi (vedi
-% manpage omonima)
-% TODO trattare getcpu, che attiene anche a NUMA, mettere qui anche
-% sched_getcpu, che potrebbe essere indipendente ma richiama getcpu
-
-%TODO trattare le funzionalità per il NUMA
-% vedi man numa e, mbind, get_mempolicy, set_mempolicy,
-% le pagine di manuale relative
-% vedere anche dove metterle...
-
-% \subsection{La gestione dei moduli}
-% \label{sec:kernel_modules}
-
-% da fare
-
-%TODO trattare init_module e finit_module (quest'ultima introdotta con il
-%kernel 3.8)
-
-%%%% Altre cose di cui non è chiara la collocazione:
-
-%TODO trattare membarrier, introdotta con il kernel 4.3
-% vedi http://lwn.net/Articles/369567/ http://lwn.net/Articles/369640/
-% http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b25b13ab08f616efd566347d809b4ece54570d1
-% vedi anche l'ulteriore opzione "expedited" introdotta con il kernel 4.14
-% (https://lwn.net/Articles/728795/)
-
-\section{Problematiche di programmazione multitasking}
+\section{Problematiche di programmazione \textit{multitasking}}
\label{sec:proc_multi_prog}
Benché i processi siano strutturati in modo da apparire il più possibile come
-indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
-occorre tenere conto di una serie di problematiche che normalmente non
-esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
-programma alla volta.
+indipendenti l'uno dall'altro, nella programmazione in un sistema
+\textit{multitasking} occorre tenere conto di una serie di problematiche che
+normalmente non esistono quando si ha a che fare con un sistema in cui viene
+eseguito un solo programma alla volta.
Per questo motivo, essendo questo argomento di carattere generale, ci è parso
opportuno introdurre sinteticamente queste problematiche, che ritroveremo a
che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
di interruzione in una fase intermedia.
-In un ambiente multitasking il concetto è essenziale, dato che un processo può
-essere interrotto in qualunque momento dal kernel che mette in esecuzione un
-altro processo o dalla ricezione di un segnale. Occorre pertanto essere
-accorti nei confronti delle possibili \textit{race condition} (vedi
+In un ambiente \textit{multitasking} il concetto è essenziale, dato che un
+processo può essere interrotto in qualunque momento dal kernel che mette in
+esecuzione un altro processo o dalla ricezione di un segnale. Occorre pertanto
+essere accorti nei confronti delle possibili \textit{race condition} (vedi
sez.~\ref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase
in cui non erano ancora state completate.
accede alla stessa risorsa quando ancora non tutti i passi sono stati
completati.
-Dato che in un sistema multitasking ogni processo può essere interrotto in
-qualunque momento per farne subentrare un altro in esecuzione, niente può
-assicurare un preciso ordine di esecuzione fra processi diversi o che una
-sezione di un programma possa essere eseguita senza interruzioni da parte di
-altri. Queste situazioni comportano pertanto errori estremamente subdoli e
-difficili da tracciare, in quanto nella maggior parte dei casi tutto
-funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
+Dato che in un sistema \textit{multitasking} ogni processo può essere
+interrotto in qualunque momento per farne subentrare un altro in esecuzione,
+niente può assicurare un preciso ordine di esecuzione fra processi diversi o
+che una sezione di un programma possa essere eseguita senza interruzioni da
+parte di altri. Queste situazioni comportano pertanto errori estremamente
+subdoli e difficili da tracciare, in quanto nella maggior parte dei casi tutto
+funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
qualunque momento da un altro \textit{thread}. In tal caso occorre pianificare
con estrema attenzione l'uso delle variabili ed utilizzare i vari meccanismi
di sincronizzazione che anche in questo caso sono disponibili (torneremo su
-queste problematiche di questo tipo in cap.~\ref{sez:thread_xxx})
+queste problematiche di questo tipo in cap.~\ref{sec:pthread_sync})
\itindbeg{deadlock}
qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
un altro \textit{thread} di esecuzione senza che questo comporti nessun
problema nell'esecuzione della stessa. La problematica è comune nella
-programmazione \textit{multi-thread}, ma si hanno gli stessi problemi quando
+programmazione con i \textit{thread}, ma si hanno gli stessi problemi quando
si vogliono chiamare delle funzioni all'interno dei gestori dei segnali.
Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
% LocalWords: shmctl ioperm iopl chroot ptrace accounting swap reboot hangup
% LocalWords: vhangup mknod lease permitted inherited inheritable bounding AND
% LocalWords: capability capget capset header ESRCH undef version obj clear PT
-% LocalWords: pag ssize length proc capgetp preemptive cache runnable
+% LocalWords: pag ssize length proc capgetp preemptive cache runnable idled
% LocalWords: SIGSTOP soft slice nice niceness counter which SC switch side
% LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO COUNT
% LocalWords: yield Robin setscheduler policy param OTHER priority setparam to
% LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID panic
% LocalWords: loader EISDIR SIGTRAP uninterrutible killable EQUAL sizeof XOR
% LocalWords: destset srcset ALLOC num cpus setsize emacs pager getty TID
-% LocalWords: reaper SUBREAPER Library futex
+% LocalWords: reaper SUBREAPER Library futex klogd named rpc statd NPROC
+% LocalWords: EACCESS EBADF EBUSY ENXIO EOPNOTSUPP DISABLE tracer Yama
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff