diff options
author | David Howells <dhowells@redhat.com> | 2019-04-25 16:26:50 +0300 |
---|---|---|
committer | David Howells <dhowells@redhat.com> | 2019-04-25 16:26:50 +0300 |
commit | 4be5975aea154e164696128d049dec9ed341585c (patch) | |
tree | c87c5444b7b41dac9016dcfabd6e4b1945759767 /include/trace | |
parent | 68ce801ffd82e72d5005ab5458e8b9e59f24d9cc (diff) | |
download | linux-4be5975aea154e164696128d049dec9ed341585c.tar.xz |
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>
Diffstat (limited to 'include/trace')
0 files changed, 0 insertions, 0 deletions