Mandatory locking
authorSimone Piccardi <piccardi@gnulinux.it>
Sat, 9 Nov 2002 22:33:40 +0000 (22:33 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sat, 9 Nov 2002 22:33:40 +0000 (22:33 +0000)
fileadv.tex

index 3d1c9f85c65c7571f55ff6e9e6587a33622872f8..454d91b237a8899888231001900ff6620f3c2a6e 100644 (file)
@@ -1000,7 +1000,7 @@ come maschera binaria ottenuta dall'OR di uno o pi
                              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\\
@@ -1583,9 +1583,9 @@ file descriptor che restano aperti.
 
 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}.
@@ -1593,46 +1593,47 @@ usare. Per questo motivo 
   \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}).
 
 
 
@@ -1640,22 +1641,86 @@ che specifica quale azione eseguire; i valori possibili sono riportati in
 \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}). 
+