afs: Further fix file locking
authorDavid Howells <dhowells@redhat.com>
Thu, 25 Apr 2019 13:26:50 +0000 (14:26 +0100)
committerDavid Howells <dhowells@redhat.com>
Thu, 25 Apr 2019 13:26:50 +0000 (14:26 +0100)
commit4be5975aea154e164696128d049dec9ed341585c
treec87c5444b7b41dac9016dcfabd6e4b1945759767
parent68ce801ffd82e72d5005ab5458e8b9e59f24d9cc
afs: Further fix file locking

Further fix the file locking in the afs filesystem client in a number of
ways, including:

 (1) Don't submit the operation to obtain a lock from the server in a work
     queue context, but rather do it in the process context of whoever
     issued the requesting system call.

 (2) The owner of the file_lock struct at the front of the pending_locks
     queue now owns right to talk to the server.

 (3) Write locks can be instantly granted if they don't overlap with any
     other locks *and* we have a write lock on the server.

 (4) In the event of an authentication/permission error, all other matching
     pending locks requests are also immediately aborted.

 (5) Properly use VFS core locks_lock_file_wait() to distribute the server
     lock amongst local client locks, including waiting for the lock to
     become available.

Test with:

sqlite3 /afs/.../scratch/billings.sqlite <<EOF
CREATE TABLE hosts (
    hostname varchar(80),
    shorthost varchar(80),
    room varchar(30),
    building varchar(30),
    PRIMARY KEY(shorthost)
    );
EOF

With the version of sqlite3 that I have, this should fail consistently with
EAGAIN, whether or not the program is straced (which introduces some delays
between lock syscalls).

Fixes: 0fafdc9f888b ("afs: Fix file locking")
Reported-by: Jonathan Billings <jsbillin@umich.edu>
Signed-off-by: David Howells <dhowells@redhat.com>
fs/afs/flock.c