1 File Locking Release Notes 2 3 Andy Walker <andy@lysaker.kvaerner.no> 4 5 12 May 1997 6 7 81. What's New? 9-------------- 10 111.1 Broken Flock Emulation 12-------------------------- 13 14The old flock(2) emulation in the kernel was swapped for proper BSD 15compatible flock(2) support in the 1.3.x series of kernels. With the 16release of the 2.1.x kernel series, support for the old emulation was 17totally removed, so that we don't need to carry this baggage forever. 18 19This should not cause problems for anybody, since everybody using a 2.1.x 20or 2.2.x kernel should have updated their C library to a suitable version 21anyway (see the file "linux/Documentation/Changes".) 22 231.2 Allow Mixed Locks Again 24--------------------------- 25 261.2.1 Typical Problems - Sendmail 27--------------------------------- 28Because sendmail was unable to use the old flock() emulation, many sendmail 29installations use fcntl() instead of flock(). This is true of Slackware 3.0 30for example. This gave rise to some other subtle problems if sendmail was 31configured to rebuild the alias file. Sendmail tried to lock the aliases.dir 32file with fcntl() at the same time as the GDBM routines tried to lock this 33file with flock(). With kernels before 1.3.96 this could result in deadlocks 34that, over time or under a very heavy mail load, would eventually cause the 35kernel to lock solid with deadlocked processes. 36 37 381.2.2 The Solution 39------------------ 40The solution I have chosen, after much experimentation and discussion, 41is to make flock() and fcntl() locks oblivious to each other. Both can 42exists, and neither will have any effect on the other. 43 44I wanted the two lock styles to be cooperative, but there were so many 45race and deadlock conditions that the current solution was the only 46practical one. It puts us in the same position as, for example, SunOS 474.1.x and several other commercial Unices. The only OS's that support 48cooperative flock()/fcntl() are those that emulate flock() using 49fcntl(), with all the problems that implies. 50 51 521.3 Mandatory Locking As A Mount Option 53--------------------------------------- 54 55Mandatory locking, as described in 'Documentation/mandatory.txt' was prior 56to this release a general configuration option that was valid for all 57mounted filesystems. This had a number of inherent dangers, not the least 58of which was the ability to freeze an NFS server by asking it to read a 59file for which a mandatory lock existed. 60 61From this release of the kernel, mandatory locking can be turned on and off 62on a per-file-system basis, using the mount options 'mand' and 'nomand'. 63The default is to disallow mandatory locking. The intention is that 64mandatory locking only be enabled on a local filesystem as the specific need 65arises. 66 67Until an updated version of mount(8) becomes available you may have to apply 68this patch to the mount sources (based on the version distributed with Rick 69Faith's util-linux-2.5 package): 70 71*** mount.c.orig Sat Jun 8 09:14:31 1996 72--- mount.c Sat Jun 8 09:13:02 1996 73*************** 74*** 100,105 **** 75--- 100,107 ---- 76 { "noauto", 0, MS_NOAUTO }, /* Can only be mounted explicitly */ 77 { "user", 0, MS_USER }, /* Allow ordinary user to mount */ 78 { "nouser", 1, MS_USER }, /* Forbid ordinary user to mount */ 79+ { "mand", 0, MS_MANDLOCK }, /* Allow mandatory locks on this FS */ 80+ { "nomand", 1, MS_MANDLOCK }, /* Forbid mandatory locks on this FS */ 81 /* add new options here */ 82 #ifdef MS_NOSUB 83 { "sub", 1, MS_NOSUB }, /* allow submounts */ 84