Kernel support for O_SHLOCK and O_EXLOCK?

From: H . J . Lu (hjl@lucon.org)
Date: Mon May 15 2000 - 17:05:11 EST


Hi,

Any comments on this?

H.J.

--
>> Do you happen to know if there are any plans afoot to add support for
>> the BSD-specific O_SHLOCK and O_EXLOCK flags (for open(2)) to the
>> Linux kernel?
>> 
>> It would be truly wonderful if I had a Linux kernel with support for
>> these flags right about now.
>> 
>
>Could you please tell me exactly what O_SHLOCK and O_EXLOCK do?

Certainly,

These are additional flags to open(2).

The programmer may use one or the other, but not both (I believe) in any given call to open.

The effect of using the O_SHLOCK flag is pretty much the same as if you had simply called open and then immediately called flock(fd, LOCK_SH) on the fd you got back from the call to open.

The important difference however is that by supplying this extra flag in the call to open the kernel is suppose to _guarrantee_ that both the open and the flock are done _together_ and ``atomically''. In other words is it is assured (by the kernel) that it will NOT be possible for any other process to ``sneak in'' and open/lock the relevant file between the open and the flock that are done by the process that is using the O_SHLOCK flag in its call to open.

Similarly, the call:

fd = open (filname, other_flags | O_EXLOCK, ...);

is roughly equivalent to:

fd = open (filname, other_flags, ...); flock (fd, LOCK_EX);

except that again, as for O_SHLOCK, the open and flock operations are both done together (by the kernal) and they are guarranteed to be done together ``atomically''.

You may wonder why this atomicity is important.

Well, it turns out that the traditional way of using flock() in conjunction with Berkeley DB files (in which the DB file is first opened and then, separately, locked) has been found to be seriously flawed, and it is now known that it can lead to catastrophic corruption of the Berkeley DB data base files involved.

If you would like to read more about this problem (and the somewhat ugly solutions that people have been forced to use on operating systems that do not support O_SHLOCK and O_EXLOCK) please have a look at:

http://perl.apache.org/guide/dbm.html#Lock_Wrappers_Overview

Note that this URL will take you directly to one specific section of a very long HTML page talking about data base locking issues.

You will see in this section a list of 5 different solutions to the locking problem. The very last one is the clean and simple one which uses O_SHLOCK and O_EXLOCK (where available).

If you want more information on the DB locking problem in general, please have a look at:

http://perl.apache.org/guide/dbm.html#Flawed_Locking_Methods_Which_Mus

(I know that that URL looks like it has been truncated, but that *is* the correct URL.)

Anyway, if you could ask Linux to consider implementing support (in the kernel) for these extra O_* options, I would appreciate it, and I suspect that many other folks would too. (It seems like it would be a reasonably trivial thing to add kernel support for.)

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:26 EST