mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-12-29 01:05:29 +00:00
f7c9ee0c72
The mandatory file locking got removed due to its problems, but
the fs locks documentation still points to it.
Update the text there, informing that it was removed on Kernel
5.14.
Fixes: f7e33bdbd6 ("fs: remove mandatory file locking support")
Reported-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
66 lines
2.4 KiB
ReStructuredText
66 lines
2.4 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
==========================
|
|
File Locking Release Notes
|
|
==========================
|
|
|
|
Andy Walker <andy@lysaker.kvaerner.no>
|
|
|
|
12 May 1997
|
|
|
|
|
|
1. What's New?
|
|
==============
|
|
|
|
1.1 Broken Flock Emulation
|
|
--------------------------
|
|
|
|
The old flock(2) emulation in the kernel was swapped for proper BSD
|
|
compatible flock(2) support in the 1.3.x series of kernels. With the
|
|
release of the 2.1.x kernel series, support for the old emulation has
|
|
been totally removed, so that we don't need to carry this baggage
|
|
forever.
|
|
|
|
This should not cause problems for anybody, since everybody using a
|
|
2.1.x kernel should have updated their C library to a suitable version
|
|
anyway (see the file "Documentation/process/changes.rst".)
|
|
|
|
1.2 Allow Mixed Locks Again
|
|
---------------------------
|
|
|
|
1.2.1 Typical Problems - Sendmail
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
Because sendmail was unable to use the old flock() emulation, many sendmail
|
|
installations use fcntl() instead of flock(). This is true of Slackware 3.0
|
|
for example. This gave rise to some other subtle problems if sendmail was
|
|
configured to rebuild the alias file. Sendmail tried to lock the aliases.dir
|
|
file with fcntl() at the same time as the GDBM routines tried to lock this
|
|
file with flock(). With pre 1.3.96 kernels this could result in deadlocks that,
|
|
over time, or under a very heavy mail load, would eventually cause the kernel
|
|
to lock solid with deadlocked processes.
|
|
|
|
|
|
1.2.2 The Solution
|
|
^^^^^^^^^^^^^^^^^^
|
|
The solution I have chosen, after much experimentation and discussion,
|
|
is to make flock() and fcntl() locks oblivious to each other. Both can
|
|
exists, and neither will have any effect on the other.
|
|
|
|
I wanted the two lock styles to be cooperative, but there were so many
|
|
race and deadlock conditions that the current solution was the only
|
|
practical one. It puts us in the same position as, for example, SunOS
|
|
4.1.x and several other commercial Unices. The only OS's that support
|
|
cooperative flock()/fcntl() are those that emulate flock() using
|
|
fcntl(), with all the problems that implies.
|
|
|
|
|
|
1.3 Mandatory Locking As A Mount Option
|
|
---------------------------------------
|
|
|
|
Mandatory locking was prior to this release a general configuration option
|
|
that was valid for all mounted filesystems. This had a number of inherent
|
|
dangers, not the least of which was the ability to freeze an NFS server by
|
|
asking it to read a file for which a mandatory lock existed.
|
|
|
|
Such option was dropped in Kernel v5.14.
|