%% fileadv.tex
%%
-%% Copyright (C) 2000-2018 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2024 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",
La prima modalità di \textit{file locking} che è stata implementata nei
sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
- come al \textit{record locking}, dizione utilizzata anche dal manuale delle
+ come al \textit{record locking}, dizione utilizzata anche dal manuale della
\acr{glibc}; nelle pagine di manuale si parla di \textit{discrectionary file
lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
mentre questo nome viene usato da Stevens per riferirsi al \textit{file
Il comportamento seguito in questo caso è che la funzione ha successo ed
esegue l'operazione richiesta sulla regione indicata; è compito del kernel
preoccuparsi di accorpare o dividere le voci nella lista dei \textit{file
- lock} per far si che le regioni bloccate da essa risultanti siano coerenti
+ lock} per far sì che le regioni bloccate da essa risultanti siano coerenti
con quanto necessario a soddisfare l'operazione richiesta.
\begin{figure}[!htbp]
\func{exec}. Per questo stesso motivo la funzione non è equivalente a
\func{flock} e può essere usata senza interferenze insieme a quest'ultima.
+
+\subsection{Gli \textit{open file descriptor locks}}
+\label{sec:open_file_descriptor_locks}
+
+Come illustrato in dettaglio nella precedente sez.~\ref{sec:file_posix_lock},
+la chiusura di un file su cui sono presenti dei \textit{file lock} comporta
+l'immediato rilascio degli stessi, anche se questi sono stati acquisiti da un
+processo diverso.
+
+da finire.
+
% TODO trattare i POSIX file-private lock introdotti con il 3.15,
% vedi http://lwn.net/Articles/586904/ correlato:
% http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html
% TODO il supporto è stato reso opzionale nel 4.5, verrà eliminato nel futuro
% (vedi http://lwn.net/Articles/667210/)
+% è stato eliminato nel 5.15
\itindend{file~locking}
tutti i sistemi che supportano i socket, compreso le varianti di System V ed
inserita in POSIX.1-2001; il suo prototipo è:\footnote{l'header
\texttt{sys/select.h} è stato introdotto con POSIX.1-2001, è ed presente con
- le \acr{glibc} a partire dalla versione 2.0, in precedenza, con le
- \acr{libc4} e le \acr{libc5}, occorreva includere \texttt{sys/time.h},
+ la \acr{glibc} a partire dalla versione 2.0, in precedenza, con le
+ \acr{libc4} e \acr{libc5}, occorreva includere \texttt{sys/time.h},
\texttt{sys/types.h} e \texttt{unistd.h}.}
\begin{funcproto}{
ricalcolano \param{timeout} tutte le volte. In genere questa caratteristica è
disponibile nei sistemi che derivano da System V e non è disponibile per
quelli che derivano da BSD; lo standard POSIX.1-2001 non permette questo
-comportamento e per questo motivo le \acr{glibc} nascondono il comportamento
+comportamento e per questo motivo la \acr{glibc} nasconde il comportamento
passando alla \textit{system call} una copia dell'argomento \param{timeout}.
Uno dei problemi che si presentano con l'uso di \func{select} è che il suo
vengano dichiarate nell'header \headfiled{sys/select.h}, che sostituisce i
precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
\funcd{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed
- l'header \headfile{sys/select.h}, compaiono in Linux a partire dalle
+ l'header \headfile{sys/select.h}, compaiono in Linux a partire dalla
\acr{glibc} 2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header,
- le \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
+ la \acr{glibc} 2.0 contiene una definizione sbagliata di \func{psignal},
senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
\acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
\acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
struttura \struct{timespec} (vedi fig.~\ref{fig:sys_timespec_struct}) per
indicare con maggiore precisione il timeout e non ne aggiorna il valore in
caso di interruzione. In realtà anche in questo caso la \textit{system call}
-di Linux aggiorna il valore al tempo rimanente, ma la funzione fornita dalle
+di Linux aggiorna il valore al tempo rimanente, ma la funzione fornita dalla
\acr{glibc} modifica questo comportamento passando alla \textit{system call}
una variabile locale, in modo da mantenere l'aderenza allo standard POSIX che
richiede che il valore di \param{timeout} non sia modificato.
\param{sigmask} permette di riabilitare la ricezione il segnale
contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
kernel 2.6.16, non era presente la relativa \textit{system call}, e la
- funzione era implementata nelle \acr{glibc} attraverso \func{select} (vedi
+ funzione era implementata nella \acr{glibc} attraverso \func{select} (vedi
\texttt{man select\_tut}) per cui la possibilità di \textit{race condition}
permaneva; in tale situazione si può ricorrere ad una soluzione alternativa,
chiamata \itindex{self-pipe~trick} \textit{self-pipe trick}, che consiste
risultati illustrati in precedenza. Come nel caso di \func{pselect} la
\textit{system call} che implementa \func{ppoll} restituisce, se la funzione
viene interrotta da un segnale, il tempo mancante in \param{timeout}, e come
-per \func{pselect} la funzione di libreria fornita dalle \acr{glibc} maschera
+per \func{pselect} la funzione di libreria fornita dalla \acr{glibc} maschera
questo comportamento non modificando mai il valore di \param{timeout} anche se
in questo caso non esiste nessuno standard che richieda questo comportamento.
servizio è chiamata \textit{epoll},\footnote{l'interfaccia è stata creata da
Davide Libenzi, ed è stata introdotta per la prima volta nel kernel 2.5.44,
ma la sua forma definitiva è stata raggiunta nel kernel 2.5.66, il supporto
- è stato aggiunto nelle \acr{glibc} a partire dalla versione 2.3.2.} anche se
+ è stato aggiunto nella \acr{glibc} a partire dalla versione 2.3.2.} anche se
sono state in discussione altre interfacce con le quali effettuare lo stesso
tipo di operazioni; \textit{epoll} è in grado di operare sia in modalità
\textit{level triggered} che \textit{edge triggered}.
-La prima versione di \textit{epoll} prevedeva l'apertura di uno speciale file
-di dispositivo, \texttt{/dev/epoll}, per ottenere un file descriptor da
+La prima versione di \textit{epoll} prevedeva l'uso di uno speciale file di
+dispositivo, \texttt{/dev/epoll}, per ottenere un file descriptor da
utilizzare con le funzioni dell'interfaccia ma poi si è passati all'uso di
apposite \textit{system call}. Il primo passo per usare l'interfaccia di
\textit{epoll} è pertanto quello ottenere detto file descriptor chiamando una
La seconda versione della funzione, \func{epoll\_create1} è stata introdotta
come estensione della precedente (è disponibile solo a partire dal kernel
2.6.27) per poter passare dei flag di controllo come maschera binaria in fase
-di creazione del file descriptor. Al momento l'unico valore legale
-per \param{flags} (a parte lo zero) è \constd{EPOLL\_CLOEXEC}, che consente di
+di creazione del file descriptor. Al momento l'unico valore legale per
+\param{flags} (a parte lo zero) è \constd{EPOLL\_CLOEXEC}, che consente di
impostare in maniera atomica sul file descriptor il flag di
-\textit{close-on-exec} (si è trattato il significato di \const{O\_CLOEXEC} in
-sez.~\ref{sec:file_open_close}), senza che sia necessaria una successiva
+\textit{close-on-exec} (vedi sez.~\ref{sec:proc_exec} e
+sez.~\ref{sec:file_shared_access}) senza che sia necessaria una successiva
chiamata a \func{fcntl}.
Una volta ottenuto un file descriptor per \textit{epoll} il passo successivo è
dettaglio le caratteristiche dei socket; in particolare si potrà trovare un
programma che utilizza questa interfaccia in sez.~\ref{sec:TCP_serv_epoll}.
+% TODO: trattare epoll_wait2, introdotta con il kernel 5.11 (vedi
+% https://lwn.net/Articles/837816/)
+
\itindend{epoll}
La funzione di sistema che permette di abilitare la ricezione dei segnali
tramite file descriptor è \funcd{signalfd},\footnote{in realtà quella
- riportata è l'interfaccia alla funzione fornita dalle \acr{glibc}, esistono
+ riportata è l'interfaccia alla funzione fornita dalla \acr{glibc}, esistono
infatti due versioni diverse della \textit{system call}; una prima versione,
- \func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le
+ \func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con la
\acr{glibc} 2.8 che non supporta l'argomento \texttt{flags}, ed una seconda
versione, \funcm{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
- che viene sempre usata a partire dalle \acr{glibc} 2.9, che prende un
+ che viene sempre usata a partire dalla \acr{glibc} 2.9, che prende un
argomento aggiuntivo \code{size\_t sizemask} che indica la dimensione della
- maschera dei segnali, il cui valore viene impostato automaticamente dalle
+ maschera dei segnali, il cui valore viene impostato automaticamente dalla
\acr{glibc}.} il cui prototipo è:
\begin{funcproto}{
potranno essere ricevuti normalmente una volta che si rimuova il blocco
imposto con \func{sigprocmask}.
-Oltre che con le funzioni dell'\textit{I/O multiplexing} l'uso del file
-descriptor restituito da \func{signalfd} cerca di seguire la semantica di un
-sistema unix-like anche con altre \textit{system call}; in particolare esso
+Oltre a poter essere usato con le funzioni dell'\textit{I/O multiplexing}, il
+file descriptor restituito da \func{signalfd} cerca di seguire la semantica di
+un sistema unix-like anche con altre \textit{system call}; in particolare esso
resta aperto (come ogni altro file descriptor) attraverso una chiamata ad
\func{exec}, a meno che non lo si sia creato con il flag di
-\const{SFD\_CLOEXEC} o si sia successivamente impostato il
+\const{SFD\_CLOEXEC} o si sia successivamente impostato il
\textit{close-on-exec} con \func{fcntl}. Questo comportamento corrisponde
anche alla ordinaria semantica relativa ai segnali bloccati, che restano
pendenti attraverso una \func{exec}.
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{0.90\textwidth}
+ \begin{minipage}[c]{0.95\textwidth}
\includestruct{listati/signalfd_siginfo.h}
\end{minipage}
\normalsize
\label{fig:fiforeporter_code_init}
\end{figure}
-Il contenuto di \struct{signalfd\_siginfo} ricalca da vicino quella della
-analoga struttura \struct{siginfo\_t} (illustrata in
+Il contenuto di \struct{signalfd\_siginfo} ricalca da vicino quella
+dell'analoga struttura \struct{siginfo\_t} (illustrata in
fig.~\ref{fig:sig_siginfo_t}) usata dall'interfaccia ordinaria dei segnali, e
restituisce dati simili. Come per \struct{siginfo\_t} i campi che vengono
avvalorati dipendono dal tipo di segnale e ricalcano i valori che abbiamo già
interfaccia è stata introdotta in forma considerata difettosa con il kernel
2.6.22, per cui è stata immediatamente tolta nel successivo 2.6.23 e
reintrodotta in una forma considerata adeguata nel kernel 2.6.25, il
- supporto nelle \acr{glibc} è stato introdotto a partire dalla versione
+ supporto nella \acr{glibc} è stato introdotto a partire dalla versione
2.8.6, la versione del kernel 2.6.22, presente solo su questo kernel, non è
supportata e non deve essere usata.} La prima funzione di sistema prevista,
quella che consente di creare un timer, è \funcd{timerfd\_create}, il cui
\itindbeg{file~lease}
+% TODO: questa funzionalità potrebbe essere estesa vedi:
+% https://lwn.net/Articles/796000/
+
La prima di queste funzionalità è quella del cosiddetto \textit{file lease};
questo è un meccanismo che consente ad un processo, detto \textit{lease
holder}, di essere notificato quando un altro processo, chiamato a sua volta
% TODO trattare fanotify, vedi http://lwn.net/Articles/339399/ e
% http://lwn.net/Articles/343346/ (incluso nel 2.6.36)
+% fanotify_mark() ha FAN_MARK_FILESYSTEM dal 4.20
+% fanotify() ha FAN_OPEN_EXEC dal 4.21/5.0
+% fanotify() ha FAN_REPORT_PIDFD dal 5.14
+% fanotify() ha FAN_FS_ERROR dal 5.16, vedi
+% https://docs.kernel.org/admin-guide/filesystem-monitoring.html
+% fanotify() ha FAN_RENAME dal 5.17, vedi https://kernelnewbies.org/Linux_5.17
\subsection{L'interfaccia POSIX per l'I/O asincrono}
In generale questa interfaccia è completamente astratta e può essere
implementata sia direttamente nel kernel che in \textit{user space} attraverso
l'uso di \textit{thread}. Per le versioni del kernel meno recenti esiste una
-implementazione di questa interfaccia fornita completamente delle \acr{glibc}
+implementazione di questa interfaccia fornita completamente dalla \acr{glibc}
a partire dalla versione 2.1, che è realizzata completamente in \textit{user
space}, ed è accessibile linkando i programmi con la libreria
\file{librt}. A partire dalla versione 2.5.32 è stato introdotto nel kernel
esse.
Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent}
-(illustrata in in fig.~\ref{fig:struct_sigevent}) che serve a specificare il
-modo in cui si vuole che venga effettuata la notifica del completamento delle
+(illustrata in fig.~\ref{fig:struct_sigevent}) che serve a specificare il modo
+in cui si vuole che venga effettuata la notifica del completamento delle
operazioni richieste; per la trattazione delle modalità di utilizzo della
stessa si veda quanto già visto in proposito in sez.~\ref{sec:sig_timer_adv}.
% http://bert-hubert.blogspot.de/2012/05/on-linux-asynchronous-file-io.html
% https://www.fsl.cs.sunysb.edu/~vass/linux-aio.txt
+% TODO trattare la poll API basata sull'I/O asicrono, introdotta con il kernel
+% 4.18, vedi https://lwn.net/Articles/743714/,
+% https://lwn.net/Articles/742978/, https://lwn.net/Articles/758324/
+% http://git.infradead.org/users/hch/vfs.git/commit/d2d9e26c7cb6d95d521153897910080cf56c7fad
+% Reverted
+
+% TODO trattare la nuova API per l'I/O asincrono (io_uring), introdotta con il
+% kernel 5.1, vedi https://lwn.net/Articles/776703/,
+% https://lwn.net/ml/linux-fsdevel/20190112213011.1439-1-axboe@kernel.dk/
+% altre feature correlate:
+% dal 5.11: support for the shutdown(), renameat2(), and unlinkat()
\section{Altre modalità di I/O avanzato}
\label{sec:file_advanced_io}
con \const{MAP\_PRIVATE}.\\
\const{MAP\_STACK} & Al momento è ignorato, è stato fornito (dal kernel
2.6.27) a supporto della implementazione dei
- thread nelle \acr{glibc}, per allocare memoria in
- uno spazio utilizzabile come \textit{stack} per le
- architetture hardware che richiedono un
- trattamento speciale di quest'ultimo.\\
+ \textit{thread} nella \acr{glibc}, per allocare
+ memoria in uno spazio utilizzabile come
+ \textit{stack} per le architetture hardware che
+ richiedono un trattamento speciale di
+ quest'ultimo.\\
\constd{MAP\_UNINITIALIZED}& Specifico per i sistemi embedded ed
utilizzabile dal kernel 2.6.33 solo se è stata
abilitata in fase di compilazione dello stesso
% TODO trattare MAP_FIXED_NOREPLACE vedi https://lwn.net/Articles/751651/ e
% https://lwn.net/Articles/741369/
+% TODO: verificare MAP_SYNC e MAP_SHARED_VALIDATE, vedi
+% https://lwn.net/Articles/731706/, https://lwn.net/Articles/758594/ incluse
+% con il 4.15
+
+
L'argomento \param{flags} specifica infine qual è il tipo di oggetto mappato,
le opzioni relative alle modalità con cui è effettuata la mappatura e alle
modalità con cui le modifiche alla memoria mappata vengono condivise o
% TODO aggiunta MADV_WIPEONFORK dal kernel 4.14 that causes the affected memory
% region to appear to be full of zeros in the child process after a fork. It
% differs from the existing MADV_DONTFORK in that the address range will
-% remain valid in the child (dalla notizia in https://lwn.net/Articles/733256/).
+% remain valid in the child (dalla notizia in
+% https://lwn.net/Articles/733256/).
+% TODO aggiunte MADV_COLD e MADV_PAGEOUT dal kernel 5.4, vedi
+% https://git.kernel.org/linus/9c276cc65a58 e
+% https://git.kernel.org/linus/1a4e58cce84e
+% TODO: aggiunte MADV_POPULATE_READ e MADV_POPULATE_WRITE (vedi
+% https://lwn.net/Articles/861695/)
\footnotetext{a partire dal kernel 2.6.32 è stato introdotto un meccanismo che
identifica pagine di memoria identiche e le accorpa in una unica pagina
L'argomento \param{advice} invece può assumere solo i valori indicati in
tab.~\ref{tab:posix_madvise_advice_values}, che riflettono gli analoghi di
\func{madvise}, con lo stesso effetto per tutti tranne
-\const{POSIX\_MADV\_DONTNEED}. Infatti a partire dalle \acr{glibc} 2.6
+\const{POSIX\_MADV\_DONTNEED}. Infatti a partire dalla \acr{glibc} 2.6
\const{POSIX\_MADV\_DONTNEED} viene ignorato, in quanto l'uso del
corrispondente \const{MADV\_DONTNEED} di \func{madvise} ha, per la semantica
imperativa, l'effetto immediato di far liberare le pagine da parte del kernel,
\func{sysconf} richiedendo l'argomento \const{\_SC\_IOV\_MAX} (vedi
sez.~\ref{sec:sys_limits}).
-Nel caso di Linux il limite di sistema è di 1024, però se si usano le
-\acr{glibc} queste forniscono un \textit{wrapper} per le \textit{system call}
+Nel caso di Linux il limite di sistema è di 1024, però se si usa la
+\acr{glibc} essa fornisce un \textit{wrapper} per le \textit{system call}
che si accorge se una operazione supererà il precedente limite, in tal caso i
dati verranno letti o scritti con le usuali \func{read} e \func{write} usando
-un buffer di dimensioni sufficienti appositamente allocato e sufficiente a
+un buffer di dimensioni sufficienti appositamente allocato in grado di
contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo
ma si perderà l'atomicità del trasferimento da e verso la destinazione finale.
chiamate a \func{lseek}.
% TODO trattare preadv2() e pwritev2(), introdotte con il kernel 4.6, vedi
-% http://lwn.net/Articles/670231/ ed il flag RWF_HIPRI
+% http://lwn.net/Articles/670231/ ed il flag RWF_HIPRI, anche l'aggiunta del
+% flag RWF_APPEND a pwritev2 con il kernel 4.16, vedi
+% https://lwn.net/Articles/746129/
\subsection{L'I/O diretto fra file descriptor: \func{sendfile} e
La prima funzione che è stata ideata per ottimizzare il trasferimento dei dati
fra due file descriptor è \func{sendfile}.\footnote{la funzione è stata
- introdotta con i kernel della serie 2.2, e disponibile dalle \acr{glibc}
+ introdotta con i kernel della serie 2.2, e disponibile dalla \acr{glibc}
2.1.} La funzione è presente in diverse versioni di Unix (la si ritrova ad
esempio in FreeBSD, HPUX ed altri Unix) ma non è presente né in POSIX.1-2001
né in altri standard (pertanto si eviti di utilizzarla se si devono scrivere
% TODO trattare qui copy_file_range (vedi http://lwn.net/Articles/659523/),
-% introdotta nel kernel 4.5
+% introdotta nel kernel 4.5, vedi anche https://lwn.net/Articles/846403/
\subsection{Gestione avanzata dell'accesso ai dati dei file}
\label{sec:file_fadvise}
che l'uso di \func{truncate} per estendere un file creerebbe soltanto uno
\textit{sparse file} (vedi sez.~\ref{sec:file_lseek}) senza una effettiva
allocazione dello spazio disco.} In realtà questa è la modalità con cui la
-funzione veniva realizzata nella prima versione fornita dalle \acr{glibc}, per
+funzione veniva realizzata nella prima versione fornita dalla \acr{glibc}, per
cui la funzione costituiva in sostanza soltanto una standardizzazione delle
modalità di esecuzione di questo tipo di allocazioni.
stato introdotto solo a partire dal kernel 2.6.25.} che consente di
realizzare direttamente all'interno del kernel l'allocazione dello spazio
disco così da poter realizzare una versione di \func{posix\_fallocate} con
-prestazioni molto più elevate; nelle \acr{glibc} la nuova \textit{system call}
+prestazioni molto più elevate; nella \acr{glibc} la nuova \textit{system call}
viene sfruttata per la realizzazione di \func{posix\_fallocate} a partire
dalla versione 2.10.
come funzione di libreria,\footnote{pertanto poteva essere invocata soltanto
in maniera indiretta con l'ausilio di \func{syscall}, vedi
sez.~\ref{sec:proc_syscall}, come \code{long fallocate(int fd, int mode,
- loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
+ loff\_t offset, loff\_t len)}.} ma a partire dalla \acr{glibc} 2.10 è
stato fornito un supporto esplicito; il suo prototipo è:
\begin{funcproto}{
% vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/
% http://kernelnewbies.org/Linux_2_6_23
+
% TODO aggiungere FALLOC_FL_ZERO_RANGE e FALLOC_FL_COLLAPSE_RANGE, inseriti
% nel kernel 3.15 (sul secondo vedi http://lwn.net/Articles/589260/), vedi
% anche http://lwn.net/Articles/629965/
% TODO aggiungere FALLOC_FL_INSERT vedi http://lwn.net/Articles/629965/
+% TODO aggiungere i file hints di fcntl (F_GET_RW_HINT e compagnia)
+% con RWH_WRITE_LIFE_EXTREME e RWH_WRITE_LIFE_SHORT aggiunte con
+% il kernel 4.13 (vedi https://lwn.net/Articles/727385/)
+
+\subsection{Altre funzionalità avanzate}
+\label{sec:file_seal_et_al}
+
+da fare
% TODO non so dove trattarli, ma dal 2.6.39 ci sono i file handle, vedi
-% http://lwn.net/Articles/432757/
+% http://lwn.net/Articles/432757/ (probabilmente da associare alle
+% at-functions)
+
+% TODO: trattare i file seal, vedi fcntl / F_ADD_SEAL e memfd_create
+
+% TODO: con il kernel 5.14 è stata introdotta la syscall memfd_secret, vedi
+% https://lwn.net/Articles/835342/ https://lwn.net/Articles/812325/
+% https://lwn.net/Articles/865256/
+% https://lwn.net/ml/linux-mm/20210729082900.1581359-1-rppt@kernel.org/ e
+% https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1507f51255c9
+
+% TODO trattare qui ioctl_ficlonerange ?
+
+% TODO trattare qui close_range, vedi https://lwn.net/Articles/789023/
+% dal 5.11 aggiunto CLOSE_RANGE_CLOEXEC, https://lwn.net/Articles/837816/
+
% LocalWords: dell'I locking multiplexing cap sez system call socket BSD GID