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
\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
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}.
+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
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
che si tratta di costanti, e non di una maschera binaria, i valori numerici
\begin{table}[!htb]
\footnotesize
\centering
- \begin{tabular}[c]{|l|p{8cm}|}
+ \begin{tabular}[c]{|l|p{10cm}|}
\hline
\textbf{Valore} & \textbf{Significato} \\
\hline
\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.\\
\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}
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}
\label{sec:sig_pid_fd}
-% TODO: trattare (qui?) pidfd_send_signal() introdotta con il kernel 5.1 vedi
+% 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/
-% oppure sopra in "Ulteriori funzioni di gestione"
+% 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
projects / gapil.git / blobdiff