X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=d1e2d5700dac07583c96f97ba114b144661db3f1;hp=c549360d72b6d36ecf14a60988ce7c04701b5a19;hb=72713a0d002a46946092d2168e4ea6203698fa41;hpb=4da25a549789cf3c9bdc3765553dc717c6173bcf diff --git a/signal.tex b/signal.tex index c549360..d1e2d57 100644 --- a/signal.tex +++ b/signal.tex @@ -2045,16 +2045,9 @@ da esso specificata, se \param{oldact} non è nullo il valore dell'azione corrente viene restituito indietro. Questo permette (specificando \param{act} nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal}, che non consente di ottenere l'azione corrente senza installarne una nuova. Se -sia \param{act} che \param{oldact} la funzione può essere utilizzata per -verificare, se da luogo ad un errore, se il segnale indicato è valido per la -piattaforma che si sta usando. - -Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction}, -tramite la quale si specificano tutte le caratteristiche dell'azione associata -ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è -definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo -\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere -più usato. +sia \param{act} che \param{oldact} sono nulli la funzione può essere +utilizzata per verificare che il segnale indicato sia valido per la +piattaforma che si sta usando (se non lo è darà errore). \begin{figure}[!htb] \footnotesize \centering @@ -2066,13 +2059,19 @@ più usato. \label{fig:sig_sigaction} \end{figure} +Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction}, +tramite la quale si specificano tutte le caratteristiche dell'azione associata +ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è +definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo +\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere +più usato. + Il campo \var{sa\_mask} serve ad indicare l'insieme dei segnali che devono essere bloccati durante l'esecuzione del gestore, ad essi viene comunque sempre aggiunto il segnale che ne ha causato la chiamata, a meno che non si -sia specificato con \var{sa\_flag} un comportamento diverso. Quando il -gestore ritorna comunque la maschera dei segnali bloccati (vedi -sez.~\ref{sec:sig_sigmask}) viene ripristinata al valore precedente -l'invocazione. +sia specificato con \var{sa\_flag} un comportamento diverso. Quando il gestore +ritorna la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) +viene comunque ripristinata al valore precedente l'invocazione. L'uso di questo campo permette ad esempio di risolvere il problema residuo dell'implementazione di \code{sleep} mostrata in @@ -2127,6 +2126,11 @@ tab.~\ref{tab:sig_sa_flag}. call} quando vengono interrotte dal suddetto segnale, riproduce cioè il comportamento standard di BSD.\\ + \constd{SA\_RESTORER} & Ad uso delle implementazioni delle liberie del C, + non deve essere usato nelle applicazioni, serve ad + indicare che il campo \var{sa\_restorer} contiene + l'indirizzo di un cosiddetto \textit{signal + trampoline}.\footnotemark \\ \constd{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un gestore in forma estesa usando \var{sa\_sigaction} al posto di @@ -2137,26 +2141,34 @@ tab.~\ref{tab:sig_sa_flag}. \label{tab:sig_sa_flag} \end{table} +\footnotetext{il \itindex{signal~trampoline} \textit{signal trampoline} è il + codice usato per tornare da un gestore di segnali, che originariamente + veniva inserito nello \textit{stack}, ma i kernel recenti come misura di + sicurezza impediscono l'esecuzione di codice dallo stack, per cui questo + codice viene spostato altrove (ad esempio nella libreria del C) ed il suo + indirizzo viene indicato al kernel nel campo \var{sa\_restorer}.} + Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x - con l'introduzione dei segnali \textit{real-time} (vedi + con l'itroduzione dei segnali \textit{real-time} (vedi sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune informazioni addizionali usando \var{sa\_handler} con un secondo parametro addizionale di tipo \var{sigcontext}, che adesso è deprecato.} da -specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO}, -rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler}. -Quest'ultima è quella classica usata anche con \func{signal}, mentre la prima -permette di usare un gestore più complesso, in grado di ricevere informazioni -più dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t}, -riportata in fig.~\ref{fig:sig_siginfo_t}. I due campi devono essere usati in -maniera alternativa, in certe implementazioni questi campi vengono addirittura +specificare rispettivamente attraverso i campi \var{sa\_sigaction} o +\var{sa\_handler}, a seconda dell'uso o meno del flag \const{SA\_SIGINFO}. La +forma con \var{sa\_handler} è quella classica usata anche con \func{signal}, +mentre quella con \var{sa\_sigaction} permette di usare un gestore più +complesso, in grado di ricevere informazioni più dettagliate dal sistema +attraverso la struttura \struct{siginfo\_t}, riportata in +fig.~\ref{fig:sig_siginfo_t}. I due campi devono essere usati in maniera +alternativa, in certe implementazioni questi campi vengono addirittura definiti come una \direct{union}.\footnote{la direttiva \direct{union} del linguaggio C definisce una variabile complessa, analoga a una stuttura, i cui campi indicano i diversi tipi di valori che possono essere salvati, in maniera alternativa, all'interno della stessa.} -Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile +Installando un gestore di tipo \var{sa\_sigaction} diventa possibile accedere alle informazioni restituite attraverso il puntatore a questa struttura. Tutti i segnali impostano i campi \var{si\_signo}, che riporta il numero del segnale ricevuto, \var{si\_errno}, che riporta, quando diverso da @@ -2177,19 +2189,11 @@ causato l'emissione del segnale. In generale \var{si\_code} contiene, per i segnali generici, per quelli \textit{real-time} e per tutti quelli inviati tramite da un processo con \func{kill} o affini, le informazioni circa l'origine del segnale stesso, ad -esempio se generato dal kernel, da un timer, da \func{kill}, ecc. Il valore -viene sempre espresso come una costante,\footnote{le definizioni di tutti i - valori possibili si trovano in \file{bits/siginfo.h}.} ed i valori possibili -in questo caso sono riportati in tab.~\ref{tab:sig_si_code_generic}. - -Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per -fornire una informazione specifica relativa alle motivazioni della ricezione -dello stesso; ad esempio i vari segnali di errore (\signal{SIGILL}, -\signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS}) lo usano per fornire -maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di -istruzione illecita o di violazione di memoria; mentre alcuni segnali di -controllo (\signal{SIGCHLD}, \signal{SIGTRAP} e \signal{SIGPOLL}) forniscono -altre informazioni specifiche. +esempio se generato dal kernel, da un timer, da \func{kill}, ecc. Il valore di +\var{si\_code} viene sempre espresso come una costante,\footnote{le + definizioni di tutti i valori possibili si trovano in + \file{bits/siginfo.h}.} ed i valori possibili in questo caso sono riportati +in tab.~\ref{tab:sig_si_code_generic}. \begin{table}[!htb] \footnotesize @@ -2223,6 +2227,14 @@ altre informazioni specifiche. \label{tab:sig_si_code_generic} \end{table} +Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per +fornire una informazione specifica relativa alle motivazioni della ricezione +dello stesso; ad esempio i vari segnali di errore (\signal{SIGILL}, +\signal{SIGFPE}, \signal{SIGSEGV} e \signal{SIGBUS}) lo usano per fornire +maggiori dettagli riguardo l'errore, come il tipo di errore aritmetico, di +istruzione illecita o di violazione di memoria; mentre alcuni segnali di +controllo (\signal{SIGCHLD}, \signal{SIGTRAP} e \signal{SIGPOLL}) forniscono +altre informazioni specifiche. In questo caso il valore del campo \var{si\_code} deve essere verificato nei confronti delle diverse costanti previste per ciascuno di detti segnali; dato @@ -2239,7 +2251,7 @@ riferimento. \begin{table}[!htb] \footnotesize \centering - \begin{tabular}[c]{|l|p{8cm}|} + \begin{tabular}[c]{|l|p{10cm}|} \hline \textbf{Valore} & \textbf{Significato} \\ \hline @@ -2264,20 +2276,34 @@ riferimento. \hline \constd{SEGV\_MAPERR} & Indirizzo non mappato.\\ \constd{SEGV\_ACCERR} & Permessi non validi per l'indirizzo.\\ + \constd{SEGV\_BNDERR} & Controllo sui limiti di accesso (via MPX) fallito + (dal 3.19).\\ + \constd{SEGV\_PKUERR} & Accesso negato da una protezione della memoria, + vedi sez.~\ref{sec:procadv_security_misc} (dal + 4.6).\\ \hline \constd{BUS\_ADRALN} & Allineamento dell'indirizzo non valido.\\ \constd{BUS\_ADRERR} & Indirizzo fisico inesistente.\\ - \constd{BUS\_OBJERR} & Errore hardware sull'indirizzo.\\ + \constd{BUS\_OBJERR} & Errore hardware specifico sull'indirizzo.\\ + \constd{BUS\_MCEERR\_AR}& Rilevata corruzione sulla memoria utilizzata + direttamente dal processo è richiesta un'azione.\\ + \constd{BUS\_MCEERR\_AO}& Rilevata corruzione sulla memoria su memoria non + utilizzata direttamente dal processo, l'azione + è opzionale.\\ + % https://lore.kernel.org/patchwork/patch/158250/ \hline \constd{TRAP\_BRKPT} & Breakpoint sul processo.\\ \constd{TRAP\_TRACE} & Trappola di tracciamento del processo.\\ + \constd{TRAP\_BRANCH} & Il processo ha preso una branch trap.\\ + % https://stackoverflow.com/questions/45895234/what-is-process-branch-trap + \constd{TRAP\_HWBKPT} & Breakpoint/watchpoint hardware.\\ \hline \constd{CLD\_EXITED} & Il figlio è uscito.\\ \constd{CLD\_KILLED} & Il figlio è stato terminato.\\ \constd{CLD\_DUMPED} & Il figlio è terminato in modo anormale.\\ \constd{CLD\_TRAPPED} & Un figlio tracciato ha raggiunto una trappola.\\ \constd{CLD\_STOPPED} & Il figlio è stato fermato.\\ - \constd{CLD\_CONTINUED}& Il figlio è ripartito.\\ + \constd{CLD\_CONTINUED}& Il figlio è ripartito (dal 2.6.9).\\ \hline \constd{POLL\_IN} & Disponibili dati in ingresso.\\ \constd{POLL\_OUT} & Spazio disponibile sul buffer di uscita.\\ @@ -2286,11 +2312,14 @@ riferimento. \constd{POLL\_PRI} & Disponibili dati di alta priorità in ingresso.\\ \constd{POLL\_HUP} & Il dispositivo è stato disconnesso.\\ \hline + \constd{SYS\_SECCOMP}& Innescato da una regola di \func{seccomp}, vedi + sez.~\ref{sec:procadv_seccomp} (dal 3.5).\\ + \hline \end{tabular} \caption{Valori del campo \var{si\_code} della struttura \struct{sigaction} impostati rispettivamente dai segnali \signal{SIGILL}, \signal{SIGFPE}, - \signal{SIGSEGV}, \signal{SIGBUS}, \signal{SIGCHLD}, \signal{SIGTRAP} e - \signal{SIGPOLL}/\signal{SIGIO}.} + \signal{SIGSEGV}, \signal{SIGBUS}, \signal{SIGCHLD}, \signal{SIGTRAP}, + \signal{SIGPOLL}/\signal{SIGIO} e \signal{SIGSYS}.} \label{tab:sig_si_code_special} \end{table} @@ -2497,7 +2526,7 @@ della funzione, vediamo allora come usando la nuova interfaccia è possibile ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non presenta neanche questa necessità. -\begin{figure}[!htbp] +\begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{\codesamplewidth} \includecodesample{listati/sleep.c} @@ -3655,9 +3684,6 @@ In questo ultimo paragrafo esamineremo le rimanenti funzioni di gestione dei segnali non descritte finora, relative agli aspetti meno utilizzati e più ``\textsl{esoterici}'' della interfaccia. -% TODO: trattare (qui?) pidfd_send_signal() introdotta con il kernel 5.1 vedi -% https://lwn.net/Articles/784831/ e https://lwn.net/Articles/773459/ - La prima di queste funzioni è la funzione di sistema \funcd{sigpending}, anch'essa introdotta dallo standard POSIX.1, il suo prototipo è: @@ -3838,16 +3864,21 @@ tipo \type{sigjmp\_buf}, è assolutamente identica a \func{longjmp}. \label{sec:sig_pid_fd} +% TODO: trattare (qui? oppure sopra in "Ulteriori funzioni di gestione?) +% pidfd_send_signal() introdotta con il kernel 5.1 vedi +% https://lwn.net/Articles/784831/, https://lwn.net/Articles/773459/ e +% https://lwn.net/Articles/801319/ + % TODO: Nuova subsection sui pidfd, e le funzioni correlate, in particolare: % trattare pidfd_send_signal, aggiunta con il kernel 5.1 (vedi % https://lwn.net/Articles/783052/) per mandare segnali a processi senza dover % usare un PID, vedi anche https://lwn.net/Articles/773459/, -% https://git.kernel.org/linus/3eb39f47934f -% trattare pure pidfd_open() (vedi https://lwn.net/Articles/789023/) per -% ottere un pid fd pollabile aggiunta con il kernel 5.3 -% man pidfd_send_signal su le versioni più recenti della man pages - - +% https://git.kernel.org/linus/3eb39f47934f trattare pure pidfd_open() (vedi +% https://lwn.net/Articles/789023/) per ottere un pid fd pollabile aggiunta +% con il kernel 5.3 ed il nuovo flag PIDFD_NONBLOCK aggionto con il 5.10 (vedi +% https://git.kernel.org/linus/4da9af0014b5), man pidfd_send_signal su le +% versioni più recenti della man pages trattare pidfd_getfd aggiunta con il +% kernel 5.6 % LocalWords: kernel POSIX timer shell control ctrl kill raise signal handler