манипулировать файловым дескриптором (manipulate file descriptor)
Ошибки (баги) (Bugs)
F_SETFL
It is not possible to use F_SETFL
to change the state of the
O_DSYNC
and O_SYNC
flags. Attempts to change the state of these
flags are silently ignored.
F_GETOWN
A limitation of the Linux system call conventions on some
architectures (notably i386) means that if a (negative) process
group ID to be returned by F_GETOWN
falls in the range -1 to
-4095, then the return value is wrongly interpreted by glibc as
an error in the system call; that is, the return value of fcntl
()
will be -1, and errno will contain the (positive) process group
ID. The Linux-specific F_GETOWN_EX
operation avoids this
problem. Since glibc version 2.11, glibc makes the kernel
F_GETOWN
problem invisible by implementing F_GETOWN
using
F_GETOWN_EX
.
F_SETOWN
In Linux 2.4 and earlier, there is bug that can occur when an
unprivileged process uses F_SETOWN
to specify the owner of a
socket file descriptor as a process (group) other than the
caller. In this case, fcntl
() can return -1 with errno set to
EPERM
, even when the owner process (group) is one that the caller
has permission to send signals to. Despite this error return,
the file descriptor owner is set, and signals will be sent to the
owner.
Deadlock detection
The deadlock-detection algorithm employed by the kernel when
dealing with F_SETLKW
requests can yield both false negatives
(failures to detect deadlocks, leaving a set of deadlocked
processes blocked indefinitely) and false positives (EDEADLK
errors when there is no deadlock). For example, the kernel
limits the lock depth of its dependency search to 10 steps,
meaning that circular deadlock chains that exceed that size will
not be detected. In addition, the kernel may falsely indicate a
deadlock when two or more processes created using the clone(2)
CLONE_FILES
flag place locks that appear (to the kernel) to
conflict.
Mandatory locking
The Linux implementation of mandatory locking is subject to race
conditions which render it unreliable: a write(2) call that
overlaps with a lock may modify data after the mandatory lock is
acquired; a read(2) call that overlaps with a lock may detect
changes to data that were made only after a write lock was
acquired. Similar races exist between mandatory locks and
mmap(2). It is therefore inadvisable to rely on mandatory
locking.