163526525SMauro Carvalho Chehab.. SPDX-License-Identifier: GPL-2.0
263526525SMauro Carvalho Chehab
363526525SMauro Carvalho Chehab==========================
463526525SMauro Carvalho ChehabFile Locking Release Notes
563526525SMauro Carvalho Chehab==========================
663526525SMauro Carvalho Chehab
763526525SMauro Carvalho Chehab		Andy Walker <andy@lysaker.kvaerner.no>
863526525SMauro Carvalho Chehab
963526525SMauro Carvalho Chehab			    12 May 1997
1063526525SMauro Carvalho Chehab
1163526525SMauro Carvalho Chehab
1263526525SMauro Carvalho Chehab1. What's New?
1363526525SMauro Carvalho Chehab==============
1463526525SMauro Carvalho Chehab
1563526525SMauro Carvalho Chehab1.1 Broken Flock Emulation
1663526525SMauro Carvalho Chehab--------------------------
1763526525SMauro Carvalho Chehab
1863526525SMauro Carvalho ChehabThe old flock(2) emulation in the kernel was swapped for proper BSD
1963526525SMauro Carvalho Chehabcompatible flock(2) support in the 1.3.x series of kernels. With the
2063526525SMauro Carvalho Chehabrelease of the 2.1.x kernel series, support for the old emulation has
2163526525SMauro Carvalho Chehabbeen totally removed, so that we don't need to carry this baggage
2263526525SMauro Carvalho Chehabforever.
2363526525SMauro Carvalho Chehab
2463526525SMauro Carvalho ChehabThis should not cause problems for anybody, since everybody using a
2563526525SMauro Carvalho Chehab2.1.x kernel should have updated their C library to a suitable version
2663526525SMauro Carvalho Chehabanyway (see the file "Documentation/process/changes.rst".)
2763526525SMauro Carvalho Chehab
2863526525SMauro Carvalho Chehab1.2 Allow Mixed Locks Again
2963526525SMauro Carvalho Chehab---------------------------
3063526525SMauro Carvalho Chehab
3163526525SMauro Carvalho Chehab1.2.1 Typical Problems - Sendmail
3263526525SMauro Carvalho Chehab^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3363526525SMauro Carvalho ChehabBecause sendmail was unable to use the old flock() emulation, many sendmail
3463526525SMauro Carvalho Chehabinstallations use fcntl() instead of flock(). This is true of Slackware 3.0
3563526525SMauro Carvalho Chehabfor example. This gave rise to some other subtle problems if sendmail was
3663526525SMauro Carvalho Chehabconfigured to rebuild the alias file. Sendmail tried to lock the aliases.dir
3763526525SMauro Carvalho Chehabfile with fcntl() at the same time as the GDBM routines tried to lock this
3863526525SMauro Carvalho Chehabfile with flock(). With pre 1.3.96 kernels this could result in deadlocks that,
3963526525SMauro Carvalho Chehabover time, or under a very heavy mail load, would eventually cause the kernel
4063526525SMauro Carvalho Chehabto lock solid with deadlocked processes.
4163526525SMauro Carvalho Chehab
4263526525SMauro Carvalho Chehab
4363526525SMauro Carvalho Chehab1.2.2 The Solution
4463526525SMauro Carvalho Chehab^^^^^^^^^^^^^^^^^^
4563526525SMauro Carvalho ChehabThe solution I have chosen, after much experimentation and discussion,
4663526525SMauro Carvalho Chehabis to make flock() and fcntl() locks oblivious to each other. Both can
4763526525SMauro Carvalho Chehabexists, and neither will have any effect on the other.
4863526525SMauro Carvalho Chehab
4963526525SMauro Carvalho ChehabI wanted the two lock styles to be cooperative, but there were so many
5063526525SMauro Carvalho Chehabrace and deadlock conditions that the current solution was the only
5163526525SMauro Carvalho Chehabpractical one. It puts us in the same position as, for example, SunOS
5263526525SMauro Carvalho Chehab4.1.x and several other commercial Unices. The only OS's that support
5363526525SMauro Carvalho Chehabcooperative flock()/fcntl() are those that emulate flock() using
5463526525SMauro Carvalho Chehabfcntl(), with all the problems that implies.
5563526525SMauro Carvalho Chehab
5663526525SMauro Carvalho Chehab
5763526525SMauro Carvalho Chehab1.3 Mandatory Locking As A Mount Option
5863526525SMauro Carvalho Chehab---------------------------------------
5963526525SMauro Carvalho Chehab
60*f7c9ee0cSMauro Carvalho ChehabMandatory locking was prior to this release a general configuration option
61*f7c9ee0cSMauro Carvalho Chehabthat was valid for all mounted filesystems.  This had a number of inherent
62*f7c9ee0cSMauro Carvalho Chehabdangers, not the least of which was the ability to freeze an NFS server by
63*f7c9ee0cSMauro Carvalho Chehabasking it to read a file for which a mandatory lock existed.
6463526525SMauro Carvalho Chehab
65*f7c9ee0cSMauro Carvalho ChehabSuch option was dropped in Kernel v5.14.
66