2 .\" This manpage is Copyright (C) 1992 Drew Eckhardt;
3 .\" and Copyright (C) 1993 Michael Haardt, Ian Jackson;
4 .\" and Copyright (C) 1998 Jamie Lokier;
5 .\" and Copyright (C) 2002-2010 Michael Kerrisk.
7 .\" %%%LICENSE_START(VERBATIM)
8 .\" Permission is granted to make and distribute verbatim copies of this
9 .\" manual provided the copyright notice and this permission notice are
10 .\" preserved on all copies.
12 .\" Permission is granted to copy and distribute modified versions of this
13 .\" manual under the conditions for verbatim copying, provided that the
14 .\" entire resulting derived work is distributed under the terms of a
15 .\" permission notice identical to this one.
17 .\" Since the Linux kernel and libraries are constantly changing, this
18 .\" manual page may be incorrect or out-of-date. The author(s) assume no
19 .\" responsibility for errors or omissions, or for damages resulting from
20 .\" the use of the information contained herein. The author(s) may not
21 .\" have taken the same level of care in the production of this manual,
22 .\" which is licensed free of charge, as they might when working
25 .\" Formatted or processed versions of this manual, if unaccompanied by
26 .\" the source, must acknowledge the copyright and authors of this work.
29 .\" Modified 1993-07-24 by Rik Faith <faith@cs.unc.edu>
30 .\" Modified 1995-09-26 by Andries Brouwer <aeb@cwi.nl>
31 .\" and again on 960413 and 980804 and 981223.
32 .\" Modified 1998-12-11 by Jamie Lokier <jamie@imbolc.ucc.ie>
33 .\" Applied correction by Christian Ehrhardt - aeb, 990712
34 .\" Modified 2002-04-23 by Michael Kerrisk <mtk.manpages@gmail.com>
35 .\" Added note on F_SETFL and O_DIRECT
36 .\" Complete rewrite + expansion of material on file locking
37 .\" Incorporated description of F_NOTIFY, drawing on
38 .\" Stephen Rothwell's notes in Documentation/dnotify.txt.
39 .\" Added description of F_SETLEASE and F_GETLEASE
40 .\" Corrected and polished, aeb, 020527.
41 .\" Modified 2004-03-03 by Michael Kerrisk <mtk.manpages@gmail.com>
42 .\" Modified description of file leases: fixed some errors of detail
43 .\" Replaced the term "lease contestant" by "lease breaker"
44 .\" Modified, 27 May 2004, Michael Kerrisk <mtk.manpages@gmail.com>
45 .\" Added notes on capability requirements
46 .\" Modified 2004-12-08, added O_NOATIME after note from Martin Pool
47 .\" 2004-12-10, mtk, noted F_GETOWN bug after suggestion from aeb.
48 .\" 2005-04-08 Jamie Lokier <jamie@shareable.org>, mtk
49 .\" Described behavior of F_SETOWN/F_SETSIG in
50 .\" multithreaded processes, and generally cleaned
51 .\" up the discussion of F_SETOWN.
52 .\" 2005-05-20, Johannes Nicolai <johannes.nicolai@hpi.uni-potsdam.de>,
53 .\" mtk: Noted F_SETOWN bug for socket file descriptor in Linux 2.4
54 .\" and earlier. Added text on permissions required to send signal.
55 .\" 2009-09-30, Michael Kerrisk
56 .\" Note obsolete F_SETOWN behavior with threads.
57 .\" Document F_SETOWN_EX and F_GETOWN_EX
58 .\" 2010-06-17, Michael Kerrisk
59 .\" Document F_SETPIPE_SZ and F_GETPIPE_SZ.
61 .TH FCNTL 2 2014-01-21 "Linux" "Linux Programmer's Manual"
63 fcntl \- manipulate file descriptor
66 .B #include <unistd.h>
69 .BI "int fcntl(int " fd ", int " cmd ", ... /* " arg " */ );"
73 performs one of the operations described below on the open file descriptor
75 The operation is determined by
79 can take an optional third argument.
80 Whether or not this argument is required is determined by
82 The required argument type is indicated in parentheses after each
84 name (in most cases, the required type is
86 and we identify the argument using the name
90 is specified if the argument is not required.
91 .SS Duplicating a file descriptor
93 .BR F_DUPFD " (\fIint\fP)"
94 Find the lowest numbered available file descriptor
95 greater than or equal to
97 and make it be a copy of
99 This is different from
101 which uses exactly the descriptor specified.
103 On success, the new descriptor is returned.
109 .BR F_DUPFD_CLOEXEC " (\fIint\fP; since Linux 2.6.24)"
112 but additionally set the
113 close-on-exec flag for the duplicate descriptor.
114 Specifying this flag permits a program to avoid an additional
120 For an explanation of why this flag is useful,
121 see the description of
125 .SS File descriptor flags
126 The following commands manipulate the flags associated with
128 Currently, only one such flag is defined:
130 the close-on-exec flag.
133 bit is 0, the file descriptor will remain open across an
135 otherwise it will be closed.
137 .BR F_GETFD " (\fIvoid\fP)"
138 Read the file descriptor flags;
142 .BR F_SETFD " (\fIint\fP)"
143 Set the file descriptor flags to the value specified by
145 .SS File status flags
146 Each open file description has certain associated status flags,
151 and possibly modified by
153 Duplicated file descriptors
158 etc.) refer to the same open file description, and thus
159 share the same file status flags.
161 The file status flags and their semantics are described in
164 .BR F_GETFL " (\fIvoid\fP)"
165 Get the file access mode and the file status flags;
169 .BR F_SETFL " (\fIint\fP)"
170 Set the file status flags to the value specified by
173 .RB ( O_RDONLY ", " O_WRONLY ", " O_RDWR )
174 and file creation flags
176 .BR O_CREAT ", " O_EXCL ", " O_NOCTTY ", " O_TRUNC )
180 On Linux this command can change only the
188 It is not possible to change the
192 flags; see BUGS, below.
194 .BR F_GETLK ", " F_SETLK ", and " F_SETLKW
195 are used to acquire, release, and test for the existence of record
196 locks (also known as file-segment or file-region locks).
199 is a pointer to a structure that has at least the following fields
200 (in unspecified order).
206 short l_type; /* Type of lock: F_RDLCK,
208 short l_whence; /* How to interpret l_start:
209 SEEK_SET, SEEK_CUR, SEEK_END */
210 off_t l_start; /* Starting offset for lock */
211 off_t l_len; /* Number of bytes to lock */
212 pid_t l_pid; /* PID of process blocking our lock
220 .IR l_whence ", " l_start ", and " l_len
221 fields of this structure specify the range of bytes we wish to lock.
222 Bytes past the end of the file may be locked,
223 but not bytes before the start of the file.
226 is the starting offset for the lock, and is interpreted
228 the start of the file (if
232 the current file offset (if
236 or the end of the file (if
240 In the final two cases,
242 can be a negative number provided the
243 offset does not lie before the start of the file.
246 specifies the number of bytes to be locked.
249 is positive, then the range to be locked covers bytes
252 .IR l_start + l_len \-1.
255 has the special meaning: lock all bytes starting at the
256 location specified by
257 .IR l_whence " and " l_start
258 through to the end of file, no matter how large the file grows.
260 POSIX.1-2001 allows (but does not require)
261 an implementation to support a negative
265 is negative, the interval described by
271 This is supported by Linux since kernel versions 2.4.21 and 2.5.49.
275 field can be used to place a read
280 Any number of processes may hold a read lock (shared lock)
281 on a file region, but only one process may hold a write lock
283 An exclusive lock excludes all other locks,
284 both shared and exclusive.
285 A single process can hold only one type of lock on a file region;
286 if a new lock is applied to an already-locked region,
287 then the existing lock is converted to the new lock type.
288 (Such conversions may involve splitting, shrinking, or coalescing with
289 an existing lock if the byte range specified by the new lock does not
290 precisely coincide with the range of the existing lock.)
292 .BR F_SETLK " (\fIstruct flock *\fP)"
299 or release a lock (when
303 on the bytes specified by the
304 .IR l_whence ", " l_start ", and " l_len
307 If a conflicting lock is held by another process,
308 this call returns \-1 and sets
315 .BR F_SETLKW " (\fIstruct flock *\fP)"
318 but if a conflicting lock is held on the file, then wait for that
320 If a signal is caught while waiting, then the call is interrupted
321 and (after the signal handler has returned)
322 returns immediately (with return value \-1 and
329 .BR F_GETLK " (\fIstruct flock *\fP)"
330 On input to this call,
332 describes a lock we would like to place on the file.
333 If the lock could be placed,
335 does not actually place it, but returns
341 and leaves the other fields of the structure unchanged.
342 If one or more incompatible locks would prevent
343 this lock being placed, then
345 returns details about one of these locks in the
346 .IR l_type ", " l_whence ", " l_start ", and " l_len
351 to be the PID of the process holding that lock.
353 In order to place a read lock,
355 must be open for reading.
356 In order to place a write lock,
358 must be open for writing.
359 To place both types of lock, open a file read-write.
361 As well as being removed by an explicit
363 record locks are automatically released when the process
364 terminates or if it closes
366 file descriptor referring to a file on which locks are held.
367 .\" (Additional file descriptors referring to the same file
368 .\" may have been obtained by calls to
369 .\" .BR open "(2), " dup "(2), " dup2 "(2), or " fcntl ().)
370 This is bad: it means that a process can lose the locks on
375 when for some reason a library function decides to open, read
378 Record locks are not inherited by a child created via
380 but are preserved across an
383 Because of the buffering performed by the
385 library, the use of record locking with routines in that package
386 should be avoided; use
391 .SS Mandatory locking
393 The above record locks may be either advisory or mandatory,
394 and are advisory by default.
396 Advisory locks are not enforced and are useful only between
397 cooperating processes.
399 Mandatory locks are enforced for all processes.
400 If a process tries to perform an incompatible access (e.g.,
404 on a file region that has an incompatible mandatory lock,
405 then the result depends upon whether the
407 flag is enabled for its open file description.
410 flag is not enabled, then
411 system call is blocked until the lock is removed
412 or converted to a mode that is compatible with the access.
415 flag is enabled, then the system call fails with the error
418 To make use of mandatory locks, mandatory locking must be enabled
419 both on the filesystem that contains the file to be locked,
420 and on the file itself.
421 Mandatory locking is enabled on a filesystem
422 using the "\-o mand" option to
428 Mandatory locking is enabled on a file by disabling
429 group execute permission on the file and enabling the set-group-ID
435 The Linux implementation of mandatory locking is unreliable.
445 are used to manage I/O availability signals:
447 .BR F_GETOWN " (\fIvoid\fP)"
448 Return (as the function result)
449 the process ID or process group currently receiving
453 signals for events on file descriptor
455 Process IDs are returned as positive values;
456 process group IDs are returned as negative values (but see BUGS below).
460 .BR F_SETOWN " (\fIint\fP)"
461 Set the process ID or process group ID that will receive
465 signals for events on file descriptor
469 A process ID is specified as a positive value;
470 a process group ID is specified as a negative value.
471 Most commonly, the calling process specifies itself as the owner
480 status flag on a file descriptor by using the
486 signal is sent whenever input or output becomes possible
487 on that file descriptor.
489 can be used to obtain delivery of a signal other than
491 If this permission check fails, then the signal is
494 Sending a signal to the owner process (group) specified by
496 is subject to the same permissions checks as are described for
498 where the sending process is the one that employs
500 (but see BUGS below).
502 If the file descriptor
509 signals that are delivered when out-of-band
510 data arrives on that socket.
512 is sent in any situation where
514 would report the socket as having an "exceptional condition".)
515 .\" The following appears to be rubbish. It doesn't seem to
516 .\" be true according to the kernel source, and I can write
517 .\" a program that gets a terminal-generated SIGIO even though
518 .\" it is not the foreground process group of the terminal.
521 .\" If the file descriptor
523 .\" refers to a terminal device, then SIGIO
524 .\" signals are sent to the foreground process group of the terminal.
526 The following was true in 2.6.x kernels up to and including
530 If a nonzero value is given to
532 in a multithreaded process running with a threading library
533 that supports thread groups (e.g., NPTL),
534 then a positive value given to
536 has a different meaning:
537 .\" The relevant place in the (2.6) kernel source is the
538 .\" 'switch' in fs/fcntl.c::send_sigio_to_task() -- MTK, Apr 2005
539 instead of being a process ID identifying a whole process,
540 it is a thread ID identifying a specific thread within a process.
541 Consequently, it may be necessary to pass
547 to get sensible results when
550 (In current Linux threading implementations,
551 a main thread's thread ID is the same as its process ID.
552 This means that a single-threaded program can equally use
557 Note, however, that the statements in this paragraph do not apply
560 signal generated for out-of-band data on a socket:
561 this signal is always sent to either a process or a process group,
562 depending on the value given to
564 .\" send_sigurg()/send_sigurg_to_task() bypasses
565 .\" kill_fasync()/send_sigio()/send_sigio_to_task()
566 .\" to directly call send_group_sig_info()
567 .\" -- MTK, Apr 2005 (kernel 2.6.11)
570 The above behavior was accidentally dropped in Linux 2.6.12,
571 and won't be restored.
572 From Linux 2.6.32 onward, use
578 signals at a particular thread.
580 .BR F_GETOWN_EX " (struct f_owner_ex *) (since Linux 2.6.32)"
581 Return the current file descriptor owner settings
582 as defined by a previous
585 The information is returned in the structure pointed to by
587 which has the following form:
600 field will have one of the values
607 field is a positive integer representing a thread ID, process ID,
613 .BR F_SETOWN_EX " (struct f_owner_ex *) (since Linux 2.6.32)"
614 This operation performs a similar task to
616 It allows the caller to direct I/O availability signals
617 to a specific thread, process, or process group.
618 The caller specifies the target of signals via
620 which is a pointer to a
625 field has one of the following values, which define how
631 Send the signal to the thread whose thread ID
632 (the value returned by a call to
640 Send the signal to the process whose ID
645 Send the signal to the process group whose ID
648 (Note that, unlike with
650 a process group ID is specified as a positive value here.)
653 .BR F_GETSIG " (\fIvoid\fP)"
654 Return (as the function result)
655 the signal sent when input or output becomes possible.
656 A value of zero means
659 Any other value (including
662 signal sent instead, and in this case additional info is available to
663 the signal handler if installed with
668 .BR F_SETSIG " (\fIint\fP)"
669 Set the signal sent when input or output becomes possible
670 to the value given in
672 A value of zero means to send the default
675 Any other value (including
677 is the signal to send instead, and in this case additional info
678 is available to the signal handler if installed with
681 .\" The following was true only up until 2.6.11:
683 .\" Additionally, passing a nonzero value to
685 .\" changes the signal recipient from a whole process to a specific thread
686 .\" within a process.
687 .\" See the description of
689 .\" for more details.
693 with a nonzero value, and setting
698 extra information about I/O events is passed to
704 field indicates the source is
708 field gives the file descriptor associated with the event.
710 there is no indication which file descriptors are pending, and you
711 should use the usual mechanisms
717 set etc.) to determine which file descriptors are available for I/O.
719 By selecting a real time signal (value >=
721 multiple I/O events may be queued using the same signal numbers.
722 (Queuing is dependent on available memory).
723 Extra information is available
726 is set for the signal handler, as above.
728 Note that Linux imposes a limit on the
729 number of real-time signals that may be queued to a
734 and if this limit is reached, then the kernel reverts to
737 and this signal is delivered to the entire
738 process rather than to a specific thread.
739 .\" See fs/fcntl.c::send_sigio_to_task() (2.4/2.6) sources -- MTK, Apr 05
741 Using these mechanisms, a program can implement fully asynchronous I/O
750 is specific to BSD and Linux.
755 specified in POSIX.1 is in conjunction with the use of the
758 (POSIX does not specify the
767 POSIX has asynchronous I/O and the
769 structure to achieve similar things; these are also available
770 in Linux as part of the GNU C Library (Glibc).
775 (Linux 2.4 onward) are used (respectively) to establish a new lease,
776 and retrieve the current lease, on the open file description
777 referred to by the file descriptor
779 A file lease provides a mechanism whereby the process holding
780 the lease (the "lease holder") is notified (via delivery of a signal)
781 when a process (the "lease breaker") tries to
785 the file referred to by that file descriptor.
787 .BR F_SETLEASE " (\fIint\fP)"
788 Set or remove a file lease according to which of the following
789 values is specified in the integer
794 Take out a read lease.
795 This will cause the calling process to be notified when
796 the file is opened for writing or is truncated.
797 .\" The following became true in kernel 2.6.10:
798 .\" See the man-pages-2.09 Changelog for further info.
799 A read lease can be placed only on a file descriptor that
803 Take out a write lease.
804 This will cause the caller to be notified when
805 the file is opened for reading or writing or is truncated.
806 A write lease may be placed on a file only if there are no
807 other open file descriptors for the file.
810 Remove our lease from the file.
813 Leases are associated with an open file description (see
815 This means that duplicate file descriptors (created by, for example,
819 refer to the same lease, and this lease may be modified
820 or released using any of these descriptors.
821 Furthermore, the lease is released by either an explicit
823 operation on any of these duplicate descriptors, or when all
824 such descriptors have been closed.
826 Leases may be taken out only on regular files.
827 An unprivileged process may take out a lease only on a file whose
828 UID (owner) matches the filesystem UID of the process.
831 capability may take out leases on arbitrary files.
833 .BR F_GETLEASE " (\fIvoid\fP)"
834 Indicates what type of lease is associated with the file descriptor
837 .BR F_RDLCK ", " F_WRLCK ", or " F_UNLCK ,
838 indicating, respectively, a read lease , a write lease, or no lease.
842 When a process (the "lease breaker") performs an
846 that conflicts with a lease established via
848 the system call is blocked by the kernel and
849 the kernel notifies the lease holder by sending it a signal
852 The lease holder should respond to receipt of this signal by doing
853 whatever cleanup is required in preparation for the file to be
854 accessed by another process (e.g., flushing cached buffers) and
855 then either remove or downgrade its lease.
856 A lease is removed by performing an
862 If the lease holder currently holds a write lease on the file,
863 and the lease breaker is opening the file for reading,
864 then it is sufficient for the lease holder to downgrade
865 the lease to a read lease.
866 This is done by performing an
873 If the lease holder fails to downgrade or remove the lease within
874 the number of seconds specified in
875 .I /proc/sys/fs/lease-break-time
876 then the kernel forcibly removes or downgrades the lease holder's lease.
878 Once a lease break has been initiated,
880 returns the target lease type (either
884 depending on what would be compatible with the lease breaker)
885 until the lease holder voluntarily downgrades or removes the lease or
886 the kernel forcibly does so after the lease break timer expires.
888 Once the lease has been voluntarily or forcibly removed or downgraded,
889 and assuming the lease breaker has not unblocked its system call,
890 the kernel permits the lease breaker's system call to proceed.
892 If the lease breaker's blocked
896 is interrupted by a signal handler,
897 then the system call fails with the error
899 but the other steps still occur as described above.
900 If the lease breaker is killed by a signal while blocked in
904 then the other steps still occur as described above.
905 If the lease breaker specifies the
909 then the call immediately fails with the error
911 but the other steps still occur as described above.
913 The default signal used to notify the lease holder is
915 but this can be changed using the
921 command is performed (even one specifying
924 handler is established using
926 then the handler will receive a
928 structure as its second argument, and the
930 field of this argument will hold the descriptor of the leased file
931 that has been accessed by another process.
932 (This is useful if the caller holds leases against multiple files).
933 .SS File and directory change notification (dnotify)
935 .BR F_NOTIFY " (\fIint\fP)"
937 Provide notification when the directory referred to by
939 or any of the files that it contains is changed.
940 The events to be notified are specified in
942 which is a bit mask specified by ORing together zero or more of
949 A file was accessed (read, pread, readv)
952 A file was modified (write, pwrite, writev, truncate, ftruncate).
955 A file was created (open, creat, mknod, mkdir, link, symlink, rename).
958 A file was unlinked (unlink, rename to another directory, rmdir).
961 A file was renamed within this directory (rename).
964 The attributes of a file were changed (chown, chmod, utime[s]).
968 (In order to obtain these definitions, the
970 feature test macro must be defined before including
974 Directory notifications are normally "one-shot", and the application
975 must reregister to receive further notifications.
980 then notification will remain in effect until explicitly removed.
982 .\" The following does seem a poor API-design choice...
985 requests is cumulative, with the events in
987 being added to the set already monitored.
988 To disable notification of all events, make an
994 Notification occurs via delivery of a signal.
995 The default signal is
997 but this can be changed using the
1001 In the latter case, the signal handler receives a
1003 structure as its second argument (if the handler was
1008 field of this structure contains the file descriptor which
1009 generated the notification (useful when establishing notification
1010 on multiple directories).
1012 Especially when using
1014 a real time signal should be used for notification,
1015 so that multiple notifications can be queued.
1018 New applications should use the
1020 interface (available since kernel 2.6.13),
1021 which provides a much superior interface for obtaining notifications of
1025 .SS Changing the capacity of a pipe
1027 .BR F_SETPIPE_SZ " (\fIint\fP; since Linux 2.6.35)"
1028 Change the capacity of the pipe referred to by
1033 An unprivileged process can adjust the pipe capacity to any value
1034 between the system page size and the limit defined in
1035 .IR /proc/sys/fs/pipe-max-size
1038 Attempts to set the pipe capacity below the page size are silently
1039 rounded up to the page size.
1040 Attempts by an unprivileged process to set the pipe capacity above the limit in
1041 .IR /proc/sys/fs/pipe-max-size
1044 a privileged process
1045 .RB ( CAP_SYS_RESOURCE )
1046 can override the limit.
1047 When allocating the buffer for the pipe,
1048 the kernel may use a capacity larger than
1050 if that is convenient for the implementation.
1053 operation returns the actual size used.
1054 Attempting to set the pipe capacity smaller than the amount
1055 of buffer space currently used to store data produces the error
1058 .BR F_GETPIPE_SZ " (\fIvoid\fP; since Linux 2.6.35)"
1059 Return (as the function result) the capacity of the pipe referred to by
1062 For a successful call, the return value depends on the operation:
1068 Value of file descriptor flags.
1071 Value of file status flags.
1074 Type of lease held on file descriptor.
1077 Value of descriptor owner.
1080 Value of signal sent when read or write becomes possible, or zero
1091 On error, \-1 is returned, and
1093 is set appropriately.
1096 .BR EACCES " or " EAGAIN
1097 Operation is prohibited by locks held by other processes.
1100 The operation is prohibited because the file has been memory-mapped by
1105 is not an open file descriptor, or the command was
1109 and the file descriptor open mode doesn't match with the
1110 type of lock requested.
1113 It was detected that the specified
1115 command would cause a deadlock.
1119 is outside your accessible address space.
1124 the command was interrupted by a signal; see
1127 .BR F_GETLK " and " F_SETLK ,
1128 the command was interrupted by a signal before the lock was checked or
1130 Most likely when locking a remote file (e.g., locking over
1131 NFS), but can sometimes happen locally.
1137 is negative or is greater than the maximum allowable value.
1141 is not an allowable signal number.
1146 the process already has the maximum number of file descriptors open.
1149 Too many segment locks open, lock table is full, or a remote locking
1150 protocol failed (e.g., locking over NFS).
1153 Attempted to clear the
1155 flag on a file that has the append-only attribute set.
1157 SVr4, 4.3BSD, POSIX.1-2001.
1168 are specified in POSIX.1-2001.
1173 are specified in POSIX.1-2001.
1174 (To get their definitions, define
1178 with the value 500 or greater, or define
1180 with the value 200809L or greater.)
1183 is specified in POSIX.1-2008.
1184 (To get this definition, define
1186 with the value 200809L or greater, or
1188 with the value 700 or greater.)
1203 macro to obtain these definitions.)
1205 .\" SVr4 documents additional EIO, ENOLINK and EOVERFLOW error conditions.
1209 system call was not designed to handle large file offsets
1215 system call was added in Linux 2.4.
1216 The newer system call employs a different structure for file locking,
1218 and corresponding commands,
1223 However, these details can be ignored by applications using glibc, whose
1225 wrapper function transparently employs the more recent system call
1226 where it is available.
1228 The errors returned by
1230 are different from those returned by
1233 Since kernel 2.0, there is no interaction between the types of lock
1239 Several systems have more fields in
1241 such as, for example,
1243 .\" e.g., Solaris 8 documents this field in fcntl(2), and Irix 6.5
1244 .\" documents it in fcntl(5). mtk, May 2007
1247 alone is not going to be very useful if the process holding the lock
1248 may live on a different machine.
1251 It is not possible to use
1253 to change the state of the
1258 .\" FIXME . According to POSIX.1-2001, O_SYNC should also be modifiable
1259 .\" via fcntl(2), but currently Linux does not permit this
1260 .\" See http://bugzilla.kernel.org/show_bug.cgi?id=5994
1261 Attempts to change the state of these flags are silently ignored.
1263 A limitation of the Linux system call conventions on some
1264 architectures (notably i386) means that if a (negative)
1265 process group ID to be returned by
1267 falls in the range \-1 to \-4095, then the return value is wrongly
1268 interpreted by glibc as an error in the system call;
1269 .\" glibc source: sysdeps/unix/sysv/linux/i386/sysdep.h
1270 that is, the return value of
1274 will contain the (positive) process group ID.
1277 operation avoids this problem.
1278 .\" mtk, Dec 04: some limited testing on alpha and ia64 seems to
1279 .\" indicate that ANY negative PGID value will cause F_GETOWN
1280 .\" to misinterpret the return as an error. Some other architectures
1281 .\" seem to have the same range check as i386.
1282 Since glibc version 2.11, glibc makes the kernel
1284 problem invisible by implementing
1289 In Linux 2.4 and earlier, there is bug that can occur
1290 when an unprivileged process uses
1292 to specify the owner
1293 of a socket file descriptor
1294 as a process (group) other than the caller.
1301 even when the owner process (group) is one that the caller
1302 has permission to send signals to.
1303 Despite this error return, the file descriptor owner is set,
1304 and signals will be sent to the owner.
1305 .SS Mandatory locking
1306 The implementation of mandatory locking in all known versions of Linux
1307 is subject to race conditions which render it unreliable:
1308 .\" http://marc.info/?l=linux-kernel&m=119013491707153&w=2
1311 call that overlaps with a lock may modify data after the mandatory lock is
1315 call that overlaps with a lock may detect changes to data that were made
1316 only after a write lock was acquired.
1317 Similar races exist between mandatory locks and
1319 It is therefore inadvisable to rely on mandatory locking.
1326 .BR capabilities (7),
1327 .BR feature_test_macros (7)
1330 .IR mandatory-locking.txt ,
1333 in the Linux kernel source directory
1334 .IR Documentation/filesystems/
1335 (on older kernels, these files are directly under the
1338 .I mandatory-locking.txt