I have become suspicious of Section 0 of /usr/src/linux/Documentation/filesystems/mandatory-locking.txt. I am going to tell this as it unfolded, so that if I went wrong somewhere you can point it out to me. For some time I have been lecturing in computer science at the local public university. Last term, I had 75 students for "Systems Programming", and we reach a point about 2 weeks from the end where the topics become more or less optional, because the students have already been told the things necessary for all of the programming assignments. This time I had decided to go a bit beyond my own familiarity and lecture on file locking, down to mandatory locks. Naturally, wanting to get the details right, I did some browsing of documentation. It seems the Stevens & Rago text that I'm using has a pretty good section on file locking in the Advanced I/O chapter, and it agreed with what I had expected well enough. But I found a reference to this file mentioned above, and was shocked to find it began with a warning to avoid this feature. It seemed it was like the BUGS section of the linux man page for the gets() function: do not use gets. I gave up on this topic, but told my students about it. Here is the section of concern:

15 April

1996

(Updated September

2007)

0. Why you should avoid mandatory locking

-----------------------------------------

The Linux implementation is prey to a number of difficult-to-fix race

conditions which in practice make it not dependable:

- The write system call checks for a mandatory lock only

once

at its start. It is therefore possible for a lock request

to

be granted after this check but before the data is

modified.

A process may then see file data change even while a

mandatory

lock was

held.

- Similarly, an exclusive lock may be granted on a file

after

the kernel has decided to proceed with a read, but before

the

read has actually completed, and the reading process may

see

the file data in a state which should not have been

visible

to

it.

- Similar races make the claimed mutual exclusion between

lock

and mmap similarly unreliable.

But it nagged at me. For one thing, it seems pretty horrible to provide a fix for a synchronization feature that introduces race conditions. UGH. Moreover, it doesn't seem hard to fix: I can think of two approaches that both seem workable: 1) Make mandatory locks mandatory: that is, disallow any file operation on a section of the file that is not locked by the invoking process. 2) Actually lock any such section of the file on behalf of the process, and release the lock when done. Both have some details to be worked out, but it doesn't strike me as anything like impossible. But I'm not the only guy on the planet who has done stuff like this before, but here's this warning that's been there in one form or another for at least 15 years, and the feature has not been fixed. What's wrong with this picture? Does nobody in his right mind use mandatory locking? Is the entire universe of competent programmers too busy with something else? I had to think things through, which had to wait for the end of the term. First, my impression of the relevant history is that advisory locks were upgraded to mandatory to deal with the possibility of a race with a program that was not properly locking a file before access. The race conditions in mandatory locking arise only in the same circumstances -- a program is issuing file operations without owning a lock. Is this a legitimate concern? The fcntl() locks were introduced to support database operations. In most databases I've seen deployed, system administrators arrange to protect the database files from access other than through the database. So while there is certainly a lot of bad code out there, I would expect the database engine itself to do proper locking on all operations, or else that the database will be heaped with scorn and promptly thrown away. Likewise system admins who don't protect their crucial files should be treated similarly. It is true that there's a lot of bad code out there, but any project that is using locks at all is showing some effort to "get it right", and it should be easy to make the locking easily verifiable. Even advisory locks should be sufficient if all operations are performed under such a lock. So here's the question: This short bit of documentation prevented my class from hearing about an important feature of Unix OSen. I think something should be done, but I'm not sure just what. The likely candidates are: 1) Fix that section 0 so it tells the whole truth, and change its heading to something like "Cautions and concerns to observe when using advisory or mandatory locks." 2) Fix the race conditions and ditch section 0, using some method -- maybe one of my suggestions above. 3) Somebody points out that I've misunderstood the situation, proves it, and tells me to go away. As things now stand, I'm upset that section 0 exists in the current form. I only hope I'm the only fool who got misled by it. I eagerly await reactions and advice. -- Kevin O'Gorman, PhD