summaryrefslogtreecommitdiff
path: root/include/linux/fs.h
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2019-04-25 14:26:50 +0100
committerDavid Howells <dhowells@redhat.com>2019-04-25 14:26:50 +0100
commit4be5975aea154e164696128d049dec9ed341585c (patch)
treec87c5444b7b41dac9016dcfabd6e4b1945759767 /include/linux/fs.h
parent68ce801ffd82e72d5005ab5458e8b9e59f24d9cc (diff)
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/linux/fs.h')
0 files changed, 0 insertions, 0 deletions