PageRenderTime 23ms CodeModel.GetById 18ms app.highlight 1ms RepoModel.GetById 1ms app.codeStats 1ms

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