Commit | Line | Data |
---|---|---|
63526525 MCC |
1 | .. SPDX-License-Identifier: GPL-2.0 |
2 | ||
3 | ========================== | |
4 | File Locking Release Notes | |
5 | ========================== | |
1da177e4 LT |
6 | |
7 | Andy Walker <andy@lysaker.kvaerner.no> | |
8 | ||
9 | 12 May 1997 | |
10 | ||
11 | ||
12 | 1. What's New? | |
63526525 | 13 | ============== |
1da177e4 LT |
14 | |
15 | 1.1 Broken Flock Emulation | |
16 | -------------------------- | |
17 | ||
18 | The old flock(2) emulation in the kernel was swapped for proper BSD | |
19 | compatible flock(2) support in the 1.3.x series of kernels. With the | |
20 | release of the 2.1.x kernel series, support for the old emulation has | |
21 | been totally removed, so that we don't need to carry this baggage | |
22 | forever. | |
23 | ||
24 | This should not cause problems for anybody, since everybody using a | |
25 | 2.1.x kernel should have updated their C library to a suitable version | |
8c27ceff | 26 | anyway (see the file "Documentation/process/changes.rst".) |
1da177e4 LT |
27 | |
28 | 1.2 Allow Mixed Locks Again | |
29 | --------------------------- | |
30 | ||
31 | 1.2.1 Typical Problems - Sendmail | |
63526525 | 32 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
1da177e4 LT |
33 | Because sendmail was unable to use the old flock() emulation, many sendmail |
34 | installations use fcntl() instead of flock(). This is true of Slackware 3.0 | |
35 | for example. This gave rise to some other subtle problems if sendmail was | |
36 | configured to rebuild the alias file. Sendmail tried to lock the aliases.dir | |
37 | file with fcntl() at the same time as the GDBM routines tried to lock this | |
38 | file with flock(). With pre 1.3.96 kernels this could result in deadlocks that, | |
39 | over time, or under a very heavy mail load, would eventually cause the kernel | |
40 | to lock solid with deadlocked processes. | |
41 | ||
42 | ||
43 | 1.2.2 The Solution | |
63526525 | 44 | ^^^^^^^^^^^^^^^^^^ |
1da177e4 LT |
45 | The solution I have chosen, after much experimentation and discussion, |
46 | is to make flock() and fcntl() locks oblivious to each other. Both can | |
47 | exists, and neither will have any effect on the other. | |
48 | ||
49 | I wanted the two lock styles to be cooperative, but there were so many | |
50 | race and deadlock conditions that the current solution was the only | |
51 | practical one. It puts us in the same position as, for example, SunOS | |
52 | 4.1.x and several other commercial Unices. The only OS's that support | |
53 | cooperative flock()/fcntl() are those that emulate flock() using | |
54 | fcntl(), with all the problems that implies. | |
55 | ||
56 | ||
57 | 1.3 Mandatory Locking As A Mount Option | |
58 | --------------------------------------- | |
59 | ||
395cf969 | 60 | Mandatory locking, as described in |
a02dcdf6 | 61 | 'Documentation/filesystems/mandatory-locking.rst' was prior to this release a |
395cf969 PB |
62 | general configuration option that was valid for all mounted filesystems. This |
63 | had a number of inherent dangers, not the least of which was the ability to | |
64 | freeze an NFS server by asking it to read a file for which a mandatory lock | |
65 | existed. | |
1da177e4 LT |
66 | |
67 | From this release of the kernel, mandatory locking can be turned on and off | |
68 | on a per-filesystem basis, using the mount options 'mand' and 'nomand'. | |
69 | The default is to disallow mandatory locking. The intention is that | |
70 | mandatory locking only be enabled on a local filesystem as the specific need | |
71 | arises. | |
72 |