bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Regarding file record locking patches


From: Svante Signell
Subject: Regarding file record locking patches
Date: Mon, 19 Dec 2016 18:25:58 +0100

HI,

I'm about to submit patches for file record locking a third time. I have still
some comment/questions before doing that:

According to POSIX.1-2008:
Regular files:
F_SETLK can establish shared (or read) locks (F_RDLCK) or exclusive (or write)
locks (F_WRLCK), as well as to remove either type of lock (F_UNLCK).

F_SETLKW:
This command shall be equivalent to F_SETLK except that if a shared or exclusive
lock is blocked by other locks, the thread shall wait until the request can be
satisfied.
 
When a shared lock is set on a segment of a file, other processes shall be able
to set shared locks on that segment or a portion of it. A shared lock prevents
any other process from setting an exclusive lock on any portion of the protected
area. A request for a shared lock shall fail if the file descriptor was not
opened with read access.

An exclusive lock shall prevent any other process from setting a shared lock or
an exclusive lock on any portion of the protected area. A request for an
exclusive lock shall fail if the file descriptor was not opened with write
access.

Case i)
The above is accomplished in libfshelp/rlock-tweak.c (fshelp_rlock_tweak) by the
two statements:
  if (lock->l_type == F_RDLCK && !(open_mode & O_READ))
    return EACCES;
  if (lock->l_type == F_WRLCK && !(open_mode & O_WRITE))
    return EACCES;
leading to that files to be read and write locked with fcntl(2) has to be opened
as O_RDWR.

Case ii)
However, for flock(2) this in not the situation, files can be write locked even
if opened read-only and vice versa. This has been fixed with the following
statements in libdiskfs/file-lock.c(diskfs_S_file_lock) and libnetfs/file-
lock.c(netfs_S_file_lock):
  if ((open_mode & O_RDONLY) && !(open_mode & O_WRONLY)) open_mode |= O_WRONLY;
  if (!(open_mode & O_RDONLY) && (open_mode & O_WRONLY)) open_mode |= O_RDONLY;

Regarding other files, e.g. /dev/null, POSIX states:
The following values for cmd are available for advisory record locking. Record
locking shall be supported for regular files, and may be supported for other
files.

It seems like the open mode for /dev/null does not contain O_READ/O_WRITE flags
making flock tests as well as fcntl tests fail, when proxied through
libtrivfs/file-lock.c (trivfs_S_file_lock).

Lifting the check in Case ii) to always result in O_RDWR makes flock checks work
also for /dev/null, but not for fcntl. However, locking is not exclusive and
doesn't work as expected (compared to e.g. linux).

Lifting the requirements in Case i) makes fcntl work also with files/devices
opened with open mode 0, which violates POSIX, as well as doesn't work as
expected (compared to e.g. linux).

Any advice given here is appreciated. Maybe the special devices, should be
opened with modes similar to regular files?
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]