mappate. \\
\macro{MAP\_GROWSDOWN} & Usato per gli stack. Indica
che la mappatura deve essere effettuata con gli
- indirizzi crecenti verso il basso.\\
+ indirizzi crescenti verso il basso.\\
\macro{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
argomenti \param{fd} e \param{offset} sono
ignorati.\footnotemark\\
Abbiamo visto come l'interfaccia POSIX per il file locking sia molto più
potente e flessibile di quella di BSD, ma è anche molto più complicata da
-usare. Per questo motivo è disponibile anche una interfaccia semplificata
-(ripresa da System V) che utilizza la funzione \func{lockf}, il cui prototipo
-è:
+usare per le varie opzioni da passare a \func{fcntl}. Per questo motivo è
+disponibile anche una interfaccia semplificata (ripresa da System V) che
+utilizza la funzione \func{lockf}, il cui prototipo è:
\begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\macro{EAGAIN}] Non è possibile acquisire il lock, e si è
+ \item[\macro{EWOULDBLOCK}] Non è possibile acquisire il lock, e si è
selezionato \macro{LOCK\_NB}, oppure l'operazione è proibita perché il
file è mappato in memoria.
\item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono
troppi segmenti di lock aperti, si è esaurita la tabella dei lock.
- \item[\macro{EDEADLK}] Si è riconosciuta una situazione di
- \textit{deadlock}.
\end{errlist}
ed inoltre \macro{EBADF}, \macro{EINVAL}.
}
\end{prototype}
Il comportamento della funzione dipende dal valore dell'argomento \param{cmd}
-che specifica quale azione eseguire; i valori possibili sono riportati in
+che specifica quale azione eseguire; i valori possibili sono riportati in
+\tabref{tab:file_lockf_type}.
+
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}[c]{|l|l|}
+ \begin{tabular}[c]{|l|p{8cm}|}
\hline
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \macro{F\_LOCK} & Richiede un \textit{exclusive lock}. Se non può essere
- ottenuto a causa di un lock preesistente la funzione
- blocca il processo chiamante fino al rilascio di
- quest'ultimo. \\
- \macro{F\_TLOCK}& Stesso comportamento di \macro{F\_LOCK} ma la funzione
- ritorna sempre subito, segnalando un errore quando il
- lock non può essere acquisito. \\
- \macro{F\_ULOCK}& Sblocca il file.\\
- \macro{F\_TEST} & Controlla il lock, la funzione restituisce 0 se il file
- non ha lock, o i lock appartengono al processo corrente,
- e -1, con un errore di \macro{EACCES}, se altri processi
- detengono un lock sul file.\\
+ \macro{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono
+ mantenere un lock condiviso sullo stesso file.\\
+ \macro{LOCK\_EX}& Richiede un \textit{exclusive lock}. Un solo processo
+ alla volta può mantenere un lock esclusivo su un file. \\
+ \macro{LOCK\_UN}& Sblocca il file.\\
+ \macro{LOCK\_NB}& Non blocca la funzione quando il lock non è disponibile,
+ si specifica sempre insieme ad una delle altre operazioni
+ con un OR aritmetico dei valori.\\
\hline
\end{tabular}
\caption{Valori possibili per il campo \var{cmd} di \func{lockf}.}
\label{tab:file_lockf_type}
\end{table}
+Qualora il lock non possa essere acquisito, a meno di non aver specificato
+\macro{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso.
+Dato che la funzione è implementata utilizzando \func{fcntl} la semantica
+delle operazioni è la stessa di quest'ultima (pertanto la funzione non è
+affatto equivalente a \func{flock}).
\label{sec:file_mand_locking}
Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
-per introdurre un file locking che come dice il nome, fosse effettivo
+per introdurre un file locking che, come dice il nome, fosse effettivo
indipendentemente dai controlli eseguiti da un processo. Con il
\textit{mandatory locking} infatti è possibile far eseguire il blocco del file
-direttamente al sistema, così che anche qualora non si predisponessero le
+direttamente al sistema, così che, anche qualora non si predisponessero le
opportune verifiche nei processi, questo verrebbe comunque rispettato.
Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
-utilizzo particolare del bit \acr{suid}. Se si ricorda quanto esposto in
-\secref{sec:file_suid_sgid}), esso viene di norma utilizzato per cambiare
-l'userid effettivo con cui viene eseguito un programma, ed è pertanto sempre
-associato alla presenza del permesso di esecuzione. Impostando questo bit su
-un file senza permesso di esecuzione in un sistema che supporta il
-\textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il file
-in questione. In questo modo una combinazione dei permessi originariamente non
-contemplata, in quanto senza significato, diventa l'indicazione della presenza
-o meno del \textit{mandatory locking}.
+utilizzo particolare del bit \acr{sgid}. Se si ricorda quanto esposto in
+\secref{sec:file_suid_sgid}), esso viene di norma utilizzato per cambiare il
+groupid effettivo con cui viene eseguito un programma, ed è pertanto sempre
+associato alla presenza del permesso di esecuzione per il gruppo. Impostando
+questo bit su un file senza permesso di esecuzione in un sistema che supporta
+il \textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il
+file in questione. In questo modo una combinazione dei permessi
+originariamente non contemplata, in quanto senza significato, diventa
+l'indicazione della presenza o meno del \textit{mandatory
+ locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
+ \secref{sec:file_chmod} e cioè che il bit \acr{sgid} viene cancellato (come
+ misura di sicurezza) quando di scrive su un file, questo non vale quando
+ esso viene utilizzato per attivare il \textit{mandatory locking}.}
+
+L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
+neanche root può passare sopra ad un lock; pertanto un processo che blocchi un
+file cruciale può renderlo completamente inaccessibile, rendendo completamente
+inutilizzabile il sistema\footnote{il problema si potrebbe risolvere
+ rimuovendo il bit \acr{sgid}, ma non è detto che sia così facile fare questa
+ operazione con un sistema bloccato.} inoltre con il \textit{mandatory
+ locking} si può bloccare completamente un server NFS richiedendo una lettura
+su un file su cui è attivo un lock. Per questo motivo l'abilitazione del
+mandatory locking è di norma disabilitata, e deve essere attivata filesystem
+per filesystem in fase di montaggio (specificando l'apposita opzione di
+\func{mount} riportata in \tabref{tab:sys_mount_flags}, o con l'opzione
+\cmd{mand} per il comando).
+
+Si tenga presente inoltre che il \textit{mandatory locking} funziona
+sull'interfaccia POSIX di \func{fcntl}, questo significa che non ha nessun
+effetto sui lock richiesti con l'interfaccia di \func{flock}, ed inoltre che
+la granularità del lock è quella del singolo byte, come per \func{fcntl}.
+
+La sintassi di acquisizione dei lock è esattamente la stessa vista in
+precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
+mandatory lock attivato non è più necessario controllare la disponibilità di
+accesso al file, ma si potranno usare direttamente le ordinarie funzioni di
+lettura e scrittura e sarà compito del kernel gestire direttamente il file
+locking.
+
+Questo significa che in caso di read lock la lettura dal file potrà avvenire
+normalmente con \func{read}, mentre una \func{write} si bloccherà fino al
+rilascio del lock, a meno di non aver aperto il file con \macro{O\_NONBLOCK},
+nel qual caso essa ritornerà immediatamente con un errore di \macro{EAGAIN}.
+
+Se invece si è acquisito un write lock tutti i tentativi di leggere o scrivere
+sulla regione del file bloccata fermeranno il processo fino al rilascio del
+lock, a meno che il file non sia stato aperto con \macro{O\_NONBLOCK}, nel
+qual caso di nuovo si otterrà un ritorno immediato con l'errore di
+\macro{EAGAIN}.
+
+Infine occorre ricordare che le funzioni di lettura e scrittura non sono le
+sole ad operare sui contenuti di un file, e che sia \func{creat} che
+\func{open} (quando chiamata con \macro{O\_TRUNC}) effettuano dei cambiamenti,
+così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
+casi, a quanto specificato nel secondo). Queste operazioni sono assimilate a
+degli accessi in scrittura e pertanto non potranno essere eseguite (fallendo
+con un errore di \macro{EAGAIN}) su un file su cui sia presente un qualunque
+lock (le prime due sempre, la terza solo nel caso che la riduzione delle
+dimensioni del file vada a sovrapporsi ad una regione bloccata).
+
+L'ultimo aspetto della interazione del \textit{mandatory locking} con le
+funzioni di accesso ai file è quello relativo ai file mappati in memoria
+appena trattati in \secref{sec:file_memory_map}; anche in tal caso infatti,
+quando si esegue la mappatura con l'opzione \macro{MAP\_SHARED}, si ha un
+accesso al contenuto del file. Lo standard SVID prevede che sia impossibile
+eseguire il memory mapping di un file su cui sono presenti dei
+lock\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
+ impediscono anche in caso di \textit{advisory locking}, anche se questo non
+ ha molto senso.} in Linux è stata però fatta la scelta implementativa di
+seguire questo comportamento soltanto quando si chiama \func{mmap} con
+l'opzione \macro{MAP\_SHARED} (nel qual caso la funzione fallisce con il
+solito \macro{EAGAIN}).
+
projects / gapil.git / commitdiff