2007-07-16 13:40:12 +07:00
|
|
|
/* AFS file locking support
|
|
|
|
*
|
|
|
|
* Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
|
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
#define AFS_LOCK_GRANTED 0
|
|
|
|
#define AFS_LOCK_PENDING 1
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
#define AFS_LOCK_YOUR_TRY 2
|
2007-07-16 13:40:12 +07:00
|
|
|
|
2017-11-02 22:27:45 +07:00
|
|
|
struct workqueue_struct *afs_lock_manager;
|
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
static void afs_next_locker(struct afs_vnode *vnode, int error);
|
2007-07-16 13:40:12 +07:00
|
|
|
static void afs_fl_copy_lock(struct file_lock *new, struct file_lock *fl);
|
|
|
|
static void afs_fl_release_private(struct file_lock *fl);
|
|
|
|
|
2009-09-22 07:01:11 +07:00
|
|
|
static const struct file_lock_operations afs_lock_ops = {
|
2007-07-16 13:40:12 +07:00
|
|
|
.fl_copy_lock = afs_fl_copy_lock,
|
|
|
|
.fl_release_private = afs_fl_release_private,
|
|
|
|
};
|
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
static inline void afs_set_lock_state(struct afs_vnode *vnode, enum afs_lock_state state)
|
|
|
|
{
|
|
|
|
_debug("STATE %u -> %u", vnode->lock_state, state);
|
|
|
|
vnode->lock_state = state;
|
|
|
|
}
|
|
|
|
|
2019-04-25 20:26:50 +07:00
|
|
|
static atomic_t afs_file_lock_debug_id;
|
|
|
|
|
2007-07-16 13:40:12 +07:00
|
|
|
/*
|
|
|
|
* if the callback is broken on this vnode, then the lock may now be available
|
|
|
|
*/
|
|
|
|
void afs_lock_may_be_available(struct afs_vnode *vnode)
|
|
|
|
{
|
2018-10-20 06:57:57 +07:00
|
|
|
_enter("{%llx:%llu}", vnode->fid.vid, vnode->fid.vnode);
|
2007-07-16 13:40:12 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
if (vnode->lock_state != AFS_VNODE_LOCK_WAITING_FOR_CB)
|
|
|
|
return;
|
|
|
|
|
|
|
|
spin_lock(&vnode->lock);
|
|
|
|
if (vnode->lock_state == AFS_VNODE_LOCK_WAITING_FOR_CB)
|
|
|
|
afs_next_locker(vnode, 0);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, NULL, afs_flock_callback_break, 0);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
2007-07-16 13:40:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* the lock will time out in 5 minutes unless we extend it, so schedule
|
|
|
|
* extension in a bit less than that time
|
|
|
|
*/
|
|
|
|
static void afs_schedule_lock_extension(struct afs_vnode *vnode)
|
|
|
|
{
|
2019-04-25 20:26:50 +07:00
|
|
|
ktime_t expires_at, now, duration;
|
|
|
|
u64 duration_j;
|
|
|
|
|
|
|
|
expires_at = ktime_add_ms(vnode->locked_at, AFS_LOCKWAIT * 1000 / 2);
|
|
|
|
now = ktime_get_real();
|
|
|
|
duration = ktime_sub(expires_at, now);
|
|
|
|
if (duration <= 0)
|
|
|
|
duration_j = 0;
|
|
|
|
else
|
|
|
|
duration_j = nsecs_to_jiffies(ktime_to_ns(duration));
|
|
|
|
|
|
|
|
queue_delayed_work(afs_lock_manager, &vnode->lock_work, duration_j);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In the case of successful completion of a lock operation, record the time
|
|
|
|
* the reply appeared and start the lock extension timer.
|
|
|
|
*/
|
|
|
|
void afs_lock_op_done(struct afs_call *call)
|
|
|
|
{
|
|
|
|
struct afs_vnode *vnode = call->reply[0];
|
|
|
|
|
|
|
|
if (call->error == 0) {
|
|
|
|
spin_lock(&vnode->lock);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, NULL, afs_flock_timestamp, 0);
|
2019-04-25 20:26:50 +07:00
|
|
|
vnode->locked_at = call->reply_time;
|
|
|
|
afs_schedule_lock_extension(vnode);
|
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
}
|
2007-07-16 13:40:12 +07:00
|
|
|
}
|
|
|
|
|
2007-07-31 14:38:49 +07:00
|
|
|
/*
|
|
|
|
* grant one or more locks (readlocks are allowed to jump the queue if the
|
|
|
|
* first lock in the queue is itself a readlock)
|
|
|
|
* - the caller must hold the vnode lock
|
|
|
|
*/
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
static void afs_grant_locks(struct afs_vnode *vnode)
|
2007-07-31 14:38:49 +07:00
|
|
|
{
|
|
|
|
struct file_lock *p, *_p;
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
bool exclusive = (vnode->lock_type == AFS_LOCK_WRITE);
|
2007-07-31 14:38:49 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
list_for_each_entry_safe(p, _p, &vnode->pending_locks, fl_u.afs.link) {
|
|
|
|
if (!exclusive && p->fl_type == F_WRLCK)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
list_move_tail(&p->fl_u.afs.link, &vnode->granted_locks);
|
|
|
|
p->fl_u.afs.state = AFS_LOCK_GRANTED;
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_op(vnode, p, afs_flock_op_grant);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
wake_up(&p->fl_wait);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If an error is specified, reject every pending lock that matches the
|
|
|
|
* authentication and type of the lock we failed to get. If there are any
|
|
|
|
* remaining lockers, try to wake up one of them to have a go.
|
|
|
|
*/
|
|
|
|
static void afs_next_locker(struct afs_vnode *vnode, int error)
|
|
|
|
{
|
|
|
|
struct file_lock *p, *_p, *next = NULL;
|
|
|
|
struct key *key = vnode->lock_key;
|
|
|
|
unsigned int fl_type = F_RDLCK;
|
|
|
|
|
|
|
|
_enter("");
|
|
|
|
|
|
|
|
if (vnode->lock_type == AFS_LOCK_WRITE)
|
|
|
|
fl_type = F_WRLCK;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(p, _p, &vnode->pending_locks, fl_u.afs.link) {
|
|
|
|
if (error &&
|
|
|
|
p->fl_type == fl_type &&
|
|
|
|
afs_file_key(p->fl_file) == key) {
|
|
|
|
list_del_init(&p->fl_u.afs.link);
|
|
|
|
p->fl_u.afs.state = error;
|
|
|
|
wake_up(&p->fl_wait);
|
2007-07-31 14:38:49 +07:00
|
|
|
}
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
|
|
|
|
/* Select the next locker to hand off to. */
|
|
|
|
if (next &&
|
|
|
|
(next->fl_type == F_WRLCK || p->fl_type == F_RDLCK))
|
|
|
|
continue;
|
|
|
|
next = p;
|
2007-07-31 14:38:49 +07:00
|
|
|
}
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
|
|
|
|
vnode->lock_key = NULL;
|
|
|
|
key_put(key);
|
|
|
|
|
|
|
|
if (next) {
|
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_SETTING);
|
|
|
|
next->fl_u.afs.state = AFS_LOCK_YOUR_TRY;
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_op(vnode, next, afs_flock_op_wake);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
wake_up(&next->fl_wait);
|
|
|
|
} else {
|
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_NONE);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, NULL, afs_flock_no_lockers, 0);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
_leave("");
|
2007-07-31 14:38:49 +07:00
|
|
|
}
|
|
|
|
|
2019-04-25 20:26:51 +07:00
|
|
|
/*
|
|
|
|
* Kill off all waiters in the the pending lock queue due to the vnode being
|
|
|
|
* deleted.
|
|
|
|
*/
|
|
|
|
static void afs_kill_lockers_enoent(struct afs_vnode *vnode)
|
|
|
|
{
|
|
|
|
struct file_lock *p;
|
|
|
|
|
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_DELETED);
|
|
|
|
|
|
|
|
while (!list_empty(&vnode->pending_locks)) {
|
|
|
|
p = list_entry(vnode->pending_locks.next,
|
|
|
|
struct file_lock, fl_u.afs.link);
|
|
|
|
list_del_init(&p->fl_u.afs.link);
|
|
|
|
p->fl_u.afs.state = -ENOENT;
|
|
|
|
wake_up(&p->fl_wait);
|
|
|
|
}
|
|
|
|
|
|
|
|
key_put(vnode->lock_key);
|
|
|
|
vnode->lock_key = NULL;
|
|
|
|
}
|
|
|
|
|
afs: Overhaul volume and server record caching and fileserver rotation
The current code assumes that volumes and servers are per-cell and are
never shared, but this is not enforced, and, indeed, public cells do exist
that are aliases of each other. Further, an organisation can, say, set up
a public cell and a private cell with overlapping, but not identical, sets
of servers. The difference is purely in the database attached to the VL
servers.
The current code will malfunction if it sees a server in two cells as it
assumes global address -> server record mappings and that each server is in
just one cell.
Further, each server may have multiple addresses - and may have addresses
of different families (IPv4 and IPv6, say).
To this end, the following structural changes are made:
(1) Server record management is overhauled:
(a) Server records are made independent of cell. The namespace keeps
track of them, volume records have lists of them and each vnode
has a server on which its callback interest currently resides.
(b) The cell record no longer keeps a list of servers known to be in
that cell.
(c) The server records are now kept in a flat list because there's no
single address to sort on.
(d) Server records are now keyed by their UUID within the namespace.
(e) The addresses for a server are obtained with the VL.GetAddrsU
rather than with VL.GetEntryByName, using the server's UUID as a
parameter.
(f) Cached server records are garbage collected after a period of
non-use and are counted out of existence before purging is allowed
to complete. This protects the work functions against rmmod.
(g) The servers list is now in /proc/fs/afs/servers.
(2) Volume record management is overhauled:
(a) An RCU-replaceable server list is introduced. This tracks both
servers and their coresponding callback interests.
(b) The superblock is now keyed on cell record and numeric volume ID.
(c) The volume record is now tied to the superblock which mounts it,
and is activated when mounted and deactivated when unmounted.
This makes it easier to handle the cache cookie without causing a
double-use in fscache.
(d) The volume record is loaded from the VLDB using VL.GetEntryByNameU
to get the server UUID list.
(e) The volume name is updated if it is seen to have changed when the
volume is updated (the update is keyed on the volume ID).
(3) The vlocation record is got rid of and VLDB records are no longer
cached. Sufficient information is stored in the volume record, though
an update to a volume record is now no longer shared between related
volumes (volumes come in bundles of three: R/W, R/O and backup).
and the following procedural changes are made:
(1) The fileserver cursor introduced previously is now fleshed out and
used to iterate over fileservers and their addresses.
(2) Volume status is checked during iteration, and the server list is
replaced if a change is detected.
(3) Server status is checked during iteration, and the address list is
replaced if a change is detected.
(4) The abort code is saved into the address list cursor and -ECONNABORTED
returned in afs_make_call() if a remote abort happened rather than
translating the abort into an error message. This allows actions to
be taken depending on the abort code more easily.
(a) If a VMOVED abort is seen then this is handled by rechecking the
volume and restarting the iteration.
(b) If a VBUSY, VRESTARTING or VSALVAGING abort is seen then this is
handled by sleeping for a short period and retrying and/or trying
other servers that might serve that volume. A message is also
displayed once until the condition has cleared.
(c) If a VOFFLINE abort is seen, then this is handled as VBUSY for the
moment.
(d) If a VNOVOL abort is seen, the volume is rechecked in the VLDB to
see if it has been deleted; if not, the fileserver is probably
indicating that the volume couldn't be attached and needs
salvaging.
(e) If statfs() sees one of these aborts, it does not sleep, but
rather returns an error, so as not to block the umount program.
(5) The fileserver iteration functions in vnode.c are now merged into
their callers and more heavily macroised around the cursor. vnode.c
is removed.
(6) Operations on a particular vnode are serialised on that vnode because
the server will lock that vnode whilst it operates on it, so a second
op sent will just have to wait.
(7) Fileservers are probed with FS.GetCapabilities before being used.
This is where service upgrade will be done.
(8) A callback interest on a fileserver is set up before an FS operation
is performed and passed through to afs_make_call() so that it can be
set on the vnode if the operation returns a callback. The callback
interest is passed through to afs_iget() also so that it can be set
there too.
In general, record updating is done on an as-needed basis when we try to
access servers, volumes or vnodes rather than offloading it to work items
and special threads.
Notes:
(1) Pre AFS-3.4 servers are no longer supported, though this can be added
back if necessary (AFS-3.4 was released in 1998).
(2) VBUSY is retried forever for the moment at intervals of 1s.
(3) /proc/fs/afs/<cell>/servers no longer exists.
Signed-off-by: David Howells <dhowells@redhat.com>
2017-11-02 22:27:50 +07:00
|
|
|
/*
|
|
|
|
* Get a lock on a file
|
|
|
|
*/
|
|
|
|
static int afs_set_lock(struct afs_vnode *vnode, struct key *key,
|
|
|
|
afs_lock_type_t type)
|
|
|
|
{
|
|
|
|
struct afs_fs_cursor fc;
|
|
|
|
int ret;
|
|
|
|
|
2018-10-20 06:57:57 +07:00
|
|
|
_enter("%s{%llx:%llu.%u},%x,%u",
|
afs: Overhaul volume and server record caching and fileserver rotation
The current code assumes that volumes and servers are per-cell and are
never shared, but this is not enforced, and, indeed, public cells do exist
that are aliases of each other. Further, an organisation can, say, set up
a public cell and a private cell with overlapping, but not identical, sets
of servers. The difference is purely in the database attached to the VL
servers.
The current code will malfunction if it sees a server in two cells as it
assumes global address -> server record mappings and that each server is in
just one cell.
Further, each server may have multiple addresses - and may have addresses
of different families (IPv4 and IPv6, say).
To this end, the following structural changes are made:
(1) Server record management is overhauled:
(a) Server records are made independent of cell. The namespace keeps
track of them, volume records have lists of them and each vnode
has a server on which its callback interest currently resides.
(b) The cell record no longer keeps a list of servers known to be in
that cell.
(c) The server records are now kept in a flat list because there's no
single address to sort on.
(d) Server records are now keyed by their UUID within the namespace.
(e) The addresses for a server are obtained with the VL.GetAddrsU
rather than with VL.GetEntryByName, using the server's UUID as a
parameter.
(f) Cached server records are garbage collected after a period of
non-use and are counted out of existence before purging is allowed
to complete. This protects the work functions against rmmod.
(g) The servers list is now in /proc/fs/afs/servers.
(2) Volume record management is overhauled:
(a) An RCU-replaceable server list is introduced. This tracks both
servers and their coresponding callback interests.
(b) The superblock is now keyed on cell record and numeric volume ID.
(c) The volume record is now tied to the superblock which mounts it,
and is activated when mounted and deactivated when unmounted.
This makes it easier to handle the cache cookie without causing a
double-use in fscache.
(d) The volume record is loaded from the VLDB using VL.GetEntryByNameU
to get the server UUID list.
(e) The volume name is updated if it is seen to have changed when the
volume is updated (the update is keyed on the volume ID).
(3) The vlocation record is got rid of and VLDB records are no longer
cached. Sufficient information is stored in the volume record, though
an update to a volume record is now no longer shared between related
volumes (volumes come in bundles of three: R/W, R/O and backup).
and the following procedural changes are made:
(1) The fileserver cursor introduced previously is now fleshed out and
used to iterate over fileservers and their addresses.
(2) Volume status is checked during iteration, and the server list is
replaced if a change is detected.
(3) Server status is checked during iteration, and the address list is
replaced if a change is detected.
(4) The abort code is saved into the address list cursor and -ECONNABORTED
returned in afs_make_call() if a remote abort happened rather than
translating the abort into an error message. This allows actions to
be taken depending on the abort code more easily.
(a) If a VMOVED abort is seen then this is handled by rechecking the
volume and restarting the iteration.
(b) If a VBUSY, VRESTARTING or VSALVAGING abort is seen then this is
handled by sleeping for a short period and retrying and/or trying
other servers that might serve that volume. A message is also
displayed once until the condition has cleared.
(c) If a VOFFLINE abort is seen, then this is handled as VBUSY for the
moment.
(d) If a VNOVOL abort is seen, the volume is rechecked in the VLDB to
see if it has been deleted; if not, the fileserver is probably
indicating that the volume couldn't be attached and needs
salvaging.
(e) If statfs() sees one of these aborts, it does not sleep, but
rather returns an error, so as not to block the umount program.
(5) The fileserver iteration functions in vnode.c are now merged into
their callers and more heavily macroised around the cursor. vnode.c
is removed.
(6) Operations on a particular vnode are serialised on that vnode because
the server will lock that vnode whilst it operates on it, so a second
op sent will just have to wait.
(7) Fileservers are probed with FS.GetCapabilities before being used.
This is where service upgrade will be done.
(8) A callback interest on a fileserver is set up before an FS operation
is performed and passed through to afs_make_call() so that it can be
set on the vnode if the operation returns a callback. The callback
interest is passed through to afs_iget() also so that it can be set
there too.
In general, record updating is done on an as-needed basis when we try to
access servers, volumes or vnodes rather than offloading it to work items
and special threads.
Notes:
(1) Pre AFS-3.4 servers are no longer supported, though this can be added
back if necessary (AFS-3.4 was released in 1998).
(2) VBUSY is retried forever for the moment at intervals of 1s.
(3) /proc/fs/afs/<cell>/servers no longer exists.
Signed-off-by: David Howells <dhowells@redhat.com>
2017-11-02 22:27:50 +07:00
|
|
|
vnode->volume->name,
|
|
|
|
vnode->fid.vid,
|
|
|
|
vnode->fid.vnode,
|
|
|
|
vnode->fid.unique,
|
|
|
|
key_serial(key), type);
|
|
|
|
|
|
|
|
ret = -ERESTARTSYS;
|
|
|
|
if (afs_begin_vnode_operation(&fc, vnode, key)) {
|
|
|
|
while (afs_select_fileserver(&fc)) {
|
2018-05-13 04:31:33 +07:00
|
|
|
fc.cb_break = afs_calc_vnode_cb_break(vnode);
|
afs: Overhaul volume and server record caching and fileserver rotation
The current code assumes that volumes and servers are per-cell and are
never shared, but this is not enforced, and, indeed, public cells do exist
that are aliases of each other. Further, an organisation can, say, set up
a public cell and a private cell with overlapping, but not identical, sets
of servers. The difference is purely in the database attached to the VL
servers.
The current code will malfunction if it sees a server in two cells as it
assumes global address -> server record mappings and that each server is in
just one cell.
Further, each server may have multiple addresses - and may have addresses
of different families (IPv4 and IPv6, say).
To this end, the following structural changes are made:
(1) Server record management is overhauled:
(a) Server records are made independent of cell. The namespace keeps
track of them, volume records have lists of them and each vnode
has a server on which its callback interest currently resides.
(b) The cell record no longer keeps a list of servers known to be in
that cell.
(c) The server records are now kept in a flat list because there's no
single address to sort on.
(d) Server records are now keyed by their UUID within the namespace.
(e) The addresses for a server are obtained with the VL.GetAddrsU
rather than with VL.GetEntryByName, using the server's UUID as a
parameter.
(f) Cached server records are garbage collected after a period of
non-use and are counted out of existence before purging is allowed
to complete. This protects the work functions against rmmod.
(g) The servers list is now in /proc/fs/afs/servers.
(2) Volume record management is overhauled:
(a) An RCU-replaceable server list is introduced. This tracks both
servers and their coresponding callback interests.
(b) The superblock is now keyed on cell record and numeric volume ID.
(c) The volume record is now tied to the superblock which mounts it,
and is activated when mounted and deactivated when unmounted.
This makes it easier to handle the cache cookie without causing a
double-use in fscache.
(d) The volume record is loaded from the VLDB using VL.GetEntryByNameU
to get the server UUID list.
(e) The volume name is updated if it is seen to have changed when the
volume is updated (the update is keyed on the volume ID).
(3) The vlocation record is got rid of and VLDB records are no longer
cached. Sufficient information is stored in the volume record, though
an update to a volume record is now no longer shared between related
volumes (volumes come in bundles of three: R/W, R/O and backup).
and the following procedural changes are made:
(1) The fileserver cursor introduced previously is now fleshed out and
used to iterate over fileservers and their addresses.
(2) Volume status is checked during iteration, and the server list is
replaced if a change is detected.
(3) Server status is checked during iteration, and the address list is
replaced if a change is detected.
(4) The abort code is saved into the address list cursor and -ECONNABORTED
returned in afs_make_call() if a remote abort happened rather than
translating the abort into an error message. This allows actions to
be taken depending on the abort code more easily.
(a) If a VMOVED abort is seen then this is handled by rechecking the
volume and restarting the iteration.
(b) If a VBUSY, VRESTARTING or VSALVAGING abort is seen then this is
handled by sleeping for a short period and retrying and/or trying
other servers that might serve that volume. A message is also
displayed once until the condition has cleared.
(c) If a VOFFLINE abort is seen, then this is handled as VBUSY for the
moment.
(d) If a VNOVOL abort is seen, the volume is rechecked in the VLDB to
see if it has been deleted; if not, the fileserver is probably
indicating that the volume couldn't be attached and needs
salvaging.
(e) If statfs() sees one of these aborts, it does not sleep, but
rather returns an error, so as not to block the umount program.
(5) The fileserver iteration functions in vnode.c are now merged into
their callers and more heavily macroised around the cursor. vnode.c
is removed.
(6) Operations on a particular vnode are serialised on that vnode because
the server will lock that vnode whilst it operates on it, so a second
op sent will just have to wait.
(7) Fileservers are probed with FS.GetCapabilities before being used.
This is where service upgrade will be done.
(8) A callback interest on a fileserver is set up before an FS operation
is performed and passed through to afs_make_call() so that it can be
set on the vnode if the operation returns a callback. The callback
interest is passed through to afs_iget() also so that it can be set
there too.
In general, record updating is done on an as-needed basis when we try to
access servers, volumes or vnodes rather than offloading it to work items
and special threads.
Notes:
(1) Pre AFS-3.4 servers are no longer supported, though this can be added
back if necessary (AFS-3.4 was released in 1998).
(2) VBUSY is retried forever for the moment at intervals of 1s.
(3) /proc/fs/afs/<cell>/servers no longer exists.
Signed-off-by: David Howells <dhowells@redhat.com>
2017-11-02 22:27:50 +07:00
|
|
|
afs_fs_set_lock(&fc, type);
|
|
|
|
}
|
|
|
|
|
|
|
|
afs_check_for_remote_deletion(&fc, fc.vnode);
|
|
|
|
afs_vnode_commit_status(&fc, vnode, fc.cb_break);
|
|
|
|
ret = afs_end_vnode_operation(&fc);
|
|
|
|
}
|
|
|
|
|
|
|
|
_leave(" = %d", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Extend a lock on a file
|
|
|
|
*/
|
|
|
|
static int afs_extend_lock(struct afs_vnode *vnode, struct key *key)
|
|
|
|
{
|
|
|
|
struct afs_fs_cursor fc;
|
|
|
|
int ret;
|
|
|
|
|
2018-10-20 06:57:57 +07:00
|
|
|
_enter("%s{%llx:%llu.%u},%x",
|
afs: Overhaul volume and server record caching and fileserver rotation
The current code assumes that volumes and servers are per-cell and are
never shared, but this is not enforced, and, indeed, public cells do exist
that are aliases of each other. Further, an organisation can, say, set up
a public cell and a private cell with overlapping, but not identical, sets
of servers. The difference is purely in the database attached to the VL
servers.
The current code will malfunction if it sees a server in two cells as it
assumes global address -> server record mappings and that each server is in
just one cell.
Further, each server may have multiple addresses - and may have addresses
of different families (IPv4 and IPv6, say).
To this end, the following structural changes are made:
(1) Server record management is overhauled:
(a) Server records are made independent of cell. The namespace keeps
track of them, volume records have lists of them and each vnode
has a server on which its callback interest currently resides.
(b) The cell record no longer keeps a list of servers known to be in
that cell.
(c) The server records are now kept in a flat list because there's no
single address to sort on.
(d) Server records are now keyed by their UUID within the namespace.
(e) The addresses for a server are obtained with the VL.GetAddrsU
rather than with VL.GetEntryByName, using the server's UUID as a
parameter.
(f) Cached server records are garbage collected after a period of
non-use and are counted out of existence before purging is allowed
to complete. This protects the work functions against rmmod.
(g) The servers list is now in /proc/fs/afs/servers.
(2) Volume record management is overhauled:
(a) An RCU-replaceable server list is introduced. This tracks both
servers and their coresponding callback interests.
(b) The superblock is now keyed on cell record and numeric volume ID.
(c) The volume record is now tied to the superblock which mounts it,
and is activated when mounted and deactivated when unmounted.
This makes it easier to handle the cache cookie without causing a
double-use in fscache.
(d) The volume record is loaded from the VLDB using VL.GetEntryByNameU
to get the server UUID list.
(e) The volume name is updated if it is seen to have changed when the
volume is updated (the update is keyed on the volume ID).
(3) The vlocation record is got rid of and VLDB records are no longer
cached. Sufficient information is stored in the volume record, though
an update to a volume record is now no longer shared between related
volumes (volumes come in bundles of three: R/W, R/O and backup).
and the following procedural changes are made:
(1) The fileserver cursor introduced previously is now fleshed out and
used to iterate over fileservers and their addresses.
(2) Volume status is checked during iteration, and the server list is
replaced if a change is detected.
(3) Server status is checked during iteration, and the address list is
replaced if a change is detected.
(4) The abort code is saved into the address list cursor and -ECONNABORTED
returned in afs_make_call() if a remote abort happened rather than
translating the abort into an error message. This allows actions to
be taken depending on the abort code more easily.
(a) If a VMOVED abort is seen then this is handled by rechecking the
volume and restarting the iteration.
(b) If a VBUSY, VRESTARTING or VSALVAGING abort is seen then this is
handled by sleeping for a short period and retrying and/or trying
other servers that might serve that volume. A message is also
displayed once until the condition has cleared.
(c) If a VOFFLINE abort is seen, then this is handled as VBUSY for the
moment.
(d) If a VNOVOL abort is seen, the volume is rechecked in the VLDB to
see if it has been deleted; if not, the fileserver is probably
indicating that the volume couldn't be attached and needs
salvaging.
(e) If statfs() sees one of these aborts, it does not sleep, but
rather returns an error, so as not to block the umount program.
(5) The fileserver iteration functions in vnode.c are now merged into
their callers and more heavily macroised around the cursor. vnode.c
is removed.
(6) Operations on a particular vnode are serialised on that vnode because
the server will lock that vnode whilst it operates on it, so a second
op sent will just have to wait.
(7) Fileservers are probed with FS.GetCapabilities before being used.
This is where service upgrade will be done.
(8) A callback interest on a fileserver is set up before an FS operation
is performed and passed through to afs_make_call() so that it can be
set on the vnode if the operation returns a callback. The callback
interest is passed through to afs_iget() also so that it can be set
there too.
In general, record updating is done on an as-needed basis when we try to
access servers, volumes or vnodes rather than offloading it to work items
and special threads.
Notes:
(1) Pre AFS-3.4 servers are no longer supported, though this can be added
back if necessary (AFS-3.4 was released in 1998).
(2) VBUSY is retried forever for the moment at intervals of 1s.
(3) /proc/fs/afs/<cell>/servers no longer exists.
Signed-off-by: David Howells <dhowells@redhat.com>
2017-11-02 22:27:50 +07:00
|
|
|
vnode->volume->name,
|
|
|
|
vnode->fid.vid,
|
|
|
|
vnode->fid.vnode,
|
|
|
|
vnode->fid.unique,
|
|
|
|
key_serial(key));
|
|
|
|
|
|
|
|
ret = -ERESTARTSYS;
|
|
|
|
if (afs_begin_vnode_operation(&fc, vnode, key)) {
|
|
|
|
while (afs_select_current_fileserver(&fc)) {
|
2018-05-13 04:31:33 +07:00
|
|
|
fc.cb_break = afs_calc_vnode_cb_break(vnode);
|
afs: Overhaul volume and server record caching and fileserver rotation
The current code assumes that volumes and servers are per-cell and are
never shared, but this is not enforced, and, indeed, public cells do exist
that are aliases of each other. Further, an organisation can, say, set up
a public cell and a private cell with overlapping, but not identical, sets
of servers. The difference is purely in the database attached to the VL
servers.
The current code will malfunction if it sees a server in two cells as it
assumes global address -> server record mappings and that each server is in
just one cell.
Further, each server may have multiple addresses - and may have addresses
of different families (IPv4 and IPv6, say).
To this end, the following structural changes are made:
(1) Server record management is overhauled:
(a) Server records are made independent of cell. The namespace keeps
track of them, volume records have lists of them and each vnode
has a server on which its callback interest currently resides.
(b) The cell record no longer keeps a list of servers known to be in
that cell.
(c) The server records are now kept in a flat list because there's no
single address to sort on.
(d) Server records are now keyed by their UUID within the namespace.
(e) The addresses for a server are obtained with the VL.GetAddrsU
rather than with VL.GetEntryByName, using the server's UUID as a
parameter.
(f) Cached server records are garbage collected after a period of
non-use and are counted out of existence before purging is allowed
to complete. This protects the work functions against rmmod.
(g) The servers list is now in /proc/fs/afs/servers.
(2) Volume record management is overhauled:
(a) An RCU-replaceable server list is introduced. This tracks both
servers and their coresponding callback interests.
(b) The superblock is now keyed on cell record and numeric volume ID.
(c) The volume record is now tied to the superblock which mounts it,
and is activated when mounted and deactivated when unmounted.
This makes it easier to handle the cache cookie without causing a
double-use in fscache.
(d) The volume record is loaded from the VLDB using VL.GetEntryByNameU
to get the server UUID list.
(e) The volume name is updated if it is seen to have changed when the
volume is updated (the update is keyed on the volume ID).
(3) The vlocation record is got rid of and VLDB records are no longer
cached. Sufficient information is stored in the volume record, though
an update to a volume record is now no longer shared between related
volumes (volumes come in bundles of three: R/W, R/O and backup).
and the following procedural changes are made:
(1) The fileserver cursor introduced previously is now fleshed out and
used to iterate over fileservers and their addresses.
(2) Volume status is checked during iteration, and the server list is
replaced if a change is detected.
(3) Server status is checked during iteration, and the address list is
replaced if a change is detected.
(4) The abort code is saved into the address list cursor and -ECONNABORTED
returned in afs_make_call() if a remote abort happened rather than
translating the abort into an error message. This allows actions to
be taken depending on the abort code more easily.
(a) If a VMOVED abort is seen then this is handled by rechecking the
volume and restarting the iteration.
(b) If a VBUSY, VRESTARTING or VSALVAGING abort is seen then this is
handled by sleeping for a short period and retrying and/or trying
other servers that might serve that volume. A message is also
displayed once until the condition has cleared.
(c) If a VOFFLINE abort is seen, then this is handled as VBUSY for the
moment.
(d) If a VNOVOL abort is seen, the volume is rechecked in the VLDB to
see if it has been deleted; if not, the fileserver is probably
indicating that the volume couldn't be attached and needs
salvaging.
(e) If statfs() sees one of these aborts, it does not sleep, but
rather returns an error, so as not to block the umount program.
(5) The fileserver iteration functions in vnode.c are now merged into
their callers and more heavily macroised around the cursor. vnode.c
is removed.
(6) Operations on a particular vnode are serialised on that vnode because
the server will lock that vnode whilst it operates on it, so a second
op sent will just have to wait.
(7) Fileservers are probed with FS.GetCapabilities before being used.
This is where service upgrade will be done.
(8) A callback interest on a fileserver is set up before an FS operation
is performed and passed through to afs_make_call() so that it can be
set on the vnode if the operation returns a callback. The callback
interest is passed through to afs_iget() also so that it can be set
there too.
In general, record updating is done on an as-needed basis when we try to
access servers, volumes or vnodes rather than offloading it to work items
and special threads.
Notes:
(1) Pre AFS-3.4 servers are no longer supported, though this can be added
back if necessary (AFS-3.4 was released in 1998).
(2) VBUSY is retried forever for the moment at intervals of 1s.
(3) /proc/fs/afs/<cell>/servers no longer exists.
Signed-off-by: David Howells <dhowells@redhat.com>
2017-11-02 22:27:50 +07:00
|
|
|
afs_fs_extend_lock(&fc);
|
|
|
|
}
|
|
|
|
|
|
|
|
afs_check_for_remote_deletion(&fc, fc.vnode);
|
|
|
|
afs_vnode_commit_status(&fc, vnode, fc.cb_break);
|
|
|
|
ret = afs_end_vnode_operation(&fc);
|
|
|
|
}
|
|
|
|
|
|
|
|
_leave(" = %d", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Release a lock on a file
|
|
|
|
*/
|
|
|
|
static int afs_release_lock(struct afs_vnode *vnode, struct key *key)
|
|
|
|
{
|
|
|
|
struct afs_fs_cursor fc;
|
|
|
|
int ret;
|
|
|
|
|
2018-10-20 06:57:57 +07:00
|
|
|
_enter("%s{%llx:%llu.%u},%x",
|
afs: Overhaul volume and server record caching and fileserver rotation
The current code assumes that volumes and servers are per-cell and are
never shared, but this is not enforced, and, indeed, public cells do exist
that are aliases of each other. Further, an organisation can, say, set up
a public cell and a private cell with overlapping, but not identical, sets
of servers. The difference is purely in the database attached to the VL
servers.
The current code will malfunction if it sees a server in two cells as it
assumes global address -> server record mappings and that each server is in
just one cell.
Further, each server may have multiple addresses - and may have addresses
of different families (IPv4 and IPv6, say).
To this end, the following structural changes are made:
(1) Server record management is overhauled:
(a) Server records are made independent of cell. The namespace keeps
track of them, volume records have lists of them and each vnode
has a server on which its callback interest currently resides.
(b) The cell record no longer keeps a list of servers known to be in
that cell.
(c) The server records are now kept in a flat list because there's no
single address to sort on.
(d) Server records are now keyed by their UUID within the namespace.
(e) The addresses for a server are obtained with the VL.GetAddrsU
rather than with VL.GetEntryByName, using the server's UUID as a
parameter.
(f) Cached server records are garbage collected after a period of
non-use and are counted out of existence before purging is allowed
to complete. This protects the work functions against rmmod.
(g) The servers list is now in /proc/fs/afs/servers.
(2) Volume record management is overhauled:
(a) An RCU-replaceable server list is introduced. This tracks both
servers and their coresponding callback interests.
(b) The superblock is now keyed on cell record and numeric volume ID.
(c) The volume record is now tied to the superblock which mounts it,
and is activated when mounted and deactivated when unmounted.
This makes it easier to handle the cache cookie without causing a
double-use in fscache.
(d) The volume record is loaded from the VLDB using VL.GetEntryByNameU
to get the server UUID list.
(e) The volume name is updated if it is seen to have changed when the
volume is updated (the update is keyed on the volume ID).
(3) The vlocation record is got rid of and VLDB records are no longer
cached. Sufficient information is stored in the volume record, though
an update to a volume record is now no longer shared between related
volumes (volumes come in bundles of three: R/W, R/O and backup).
and the following procedural changes are made:
(1) The fileserver cursor introduced previously is now fleshed out and
used to iterate over fileservers and their addresses.
(2) Volume status is checked during iteration, and the server list is
replaced if a change is detected.
(3) Server status is checked during iteration, and the address list is
replaced if a change is detected.
(4) The abort code is saved into the address list cursor and -ECONNABORTED
returned in afs_make_call() if a remote abort happened rather than
translating the abort into an error message. This allows actions to
be taken depending on the abort code more easily.
(a) If a VMOVED abort is seen then this is handled by rechecking the
volume and restarting the iteration.
(b) If a VBUSY, VRESTARTING or VSALVAGING abort is seen then this is
handled by sleeping for a short period and retrying and/or trying
other servers that might serve that volume. A message is also
displayed once until the condition has cleared.
(c) If a VOFFLINE abort is seen, then this is handled as VBUSY for the
moment.
(d) If a VNOVOL abort is seen, the volume is rechecked in the VLDB to
see if it has been deleted; if not, the fileserver is probably
indicating that the volume couldn't be attached and needs
salvaging.
(e) If statfs() sees one of these aborts, it does not sleep, but
rather returns an error, so as not to block the umount program.
(5) The fileserver iteration functions in vnode.c are now merged into
their callers and more heavily macroised around the cursor. vnode.c
is removed.
(6) Operations on a particular vnode are serialised on that vnode because
the server will lock that vnode whilst it operates on it, so a second
op sent will just have to wait.
(7) Fileservers are probed with FS.GetCapabilities before being used.
This is where service upgrade will be done.
(8) A callback interest on a fileserver is set up before an FS operation
is performed and passed through to afs_make_call() so that it can be
set on the vnode if the operation returns a callback. The callback
interest is passed through to afs_iget() also so that it can be set
there too.
In general, record updating is done on an as-needed basis when we try to
access servers, volumes or vnodes rather than offloading it to work items
and special threads.
Notes:
(1) Pre AFS-3.4 servers are no longer supported, though this can be added
back if necessary (AFS-3.4 was released in 1998).
(2) VBUSY is retried forever for the moment at intervals of 1s.
(3) /proc/fs/afs/<cell>/servers no longer exists.
Signed-off-by: David Howells <dhowells@redhat.com>
2017-11-02 22:27:50 +07:00
|
|
|
vnode->volume->name,
|
|
|
|
vnode->fid.vid,
|
|
|
|
vnode->fid.vnode,
|
|
|
|
vnode->fid.unique,
|
|
|
|
key_serial(key));
|
|
|
|
|
|
|
|
ret = -ERESTARTSYS;
|
|
|
|
if (afs_begin_vnode_operation(&fc, vnode, key)) {
|
|
|
|
while (afs_select_current_fileserver(&fc)) {
|
2018-05-13 04:31:33 +07:00
|
|
|
fc.cb_break = afs_calc_vnode_cb_break(vnode);
|
afs: Overhaul volume and server record caching and fileserver rotation
The current code assumes that volumes and servers are per-cell and are
never shared, but this is not enforced, and, indeed, public cells do exist
that are aliases of each other. Further, an organisation can, say, set up
a public cell and a private cell with overlapping, but not identical, sets
of servers. The difference is purely in the database attached to the VL
servers.
The current code will malfunction if it sees a server in two cells as it
assumes global address -> server record mappings and that each server is in
just one cell.
Further, each server may have multiple addresses - and may have addresses
of different families (IPv4 and IPv6, say).
To this end, the following structural changes are made:
(1) Server record management is overhauled:
(a) Server records are made independent of cell. The namespace keeps
track of them, volume records have lists of them and each vnode
has a server on which its callback interest currently resides.
(b) The cell record no longer keeps a list of servers known to be in
that cell.
(c) The server records are now kept in a flat list because there's no
single address to sort on.
(d) Server records are now keyed by their UUID within the namespace.
(e) The addresses for a server are obtained with the VL.GetAddrsU
rather than with VL.GetEntryByName, using the server's UUID as a
parameter.
(f) Cached server records are garbage collected after a period of
non-use and are counted out of existence before purging is allowed
to complete. This protects the work functions against rmmod.
(g) The servers list is now in /proc/fs/afs/servers.
(2) Volume record management is overhauled:
(a) An RCU-replaceable server list is introduced. This tracks both
servers and their coresponding callback interests.
(b) The superblock is now keyed on cell record and numeric volume ID.
(c) The volume record is now tied to the superblock which mounts it,
and is activated when mounted and deactivated when unmounted.
This makes it easier to handle the cache cookie without causing a
double-use in fscache.
(d) The volume record is loaded from the VLDB using VL.GetEntryByNameU
to get the server UUID list.
(e) The volume name is updated if it is seen to have changed when the
volume is updated (the update is keyed on the volume ID).
(3) The vlocation record is got rid of and VLDB records are no longer
cached. Sufficient information is stored in the volume record, though
an update to a volume record is now no longer shared between related
volumes (volumes come in bundles of three: R/W, R/O and backup).
and the following procedural changes are made:
(1) The fileserver cursor introduced previously is now fleshed out and
used to iterate over fileservers and their addresses.
(2) Volume status is checked during iteration, and the server list is
replaced if a change is detected.
(3) Server status is checked during iteration, and the address list is
replaced if a change is detected.
(4) The abort code is saved into the address list cursor and -ECONNABORTED
returned in afs_make_call() if a remote abort happened rather than
translating the abort into an error message. This allows actions to
be taken depending on the abort code more easily.
(a) If a VMOVED abort is seen then this is handled by rechecking the
volume and restarting the iteration.
(b) If a VBUSY, VRESTARTING or VSALVAGING abort is seen then this is
handled by sleeping for a short period and retrying and/or trying
other servers that might serve that volume. A message is also
displayed once until the condition has cleared.
(c) If a VOFFLINE abort is seen, then this is handled as VBUSY for the
moment.
(d) If a VNOVOL abort is seen, the volume is rechecked in the VLDB to
see if it has been deleted; if not, the fileserver is probably
indicating that the volume couldn't be attached and needs
salvaging.
(e) If statfs() sees one of these aborts, it does not sleep, but
rather returns an error, so as not to block the umount program.
(5) The fileserver iteration functions in vnode.c are now merged into
their callers and more heavily macroised around the cursor. vnode.c
is removed.
(6) Operations on a particular vnode are serialised on that vnode because
the server will lock that vnode whilst it operates on it, so a second
op sent will just have to wait.
(7) Fileservers are probed with FS.GetCapabilities before being used.
This is where service upgrade will be done.
(8) A callback interest on a fileserver is set up before an FS operation
is performed and passed through to afs_make_call() so that it can be
set on the vnode if the operation returns a callback. The callback
interest is passed through to afs_iget() also so that it can be set
there too.
In general, record updating is done on an as-needed basis when we try to
access servers, volumes or vnodes rather than offloading it to work items
and special threads.
Notes:
(1) Pre AFS-3.4 servers are no longer supported, though this can be added
back if necessary (AFS-3.4 was released in 1998).
(2) VBUSY is retried forever for the moment at intervals of 1s.
(3) /proc/fs/afs/<cell>/servers no longer exists.
Signed-off-by: David Howells <dhowells@redhat.com>
2017-11-02 22:27:50 +07:00
|
|
|
afs_fs_release_lock(&fc);
|
|
|
|
}
|
|
|
|
|
|
|
|
afs_check_for_remote_deletion(&fc, fc.vnode);
|
|
|
|
afs_vnode_commit_status(&fc, vnode, fc.cb_break);
|
|
|
|
ret = afs_end_vnode_operation(&fc);
|
|
|
|
}
|
|
|
|
|
|
|
|
_leave(" = %d", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2007-07-16 13:40:12 +07:00
|
|
|
/*
|
|
|
|
* do work for a lock, including:
|
|
|
|
* - probing for a lock we're waiting on but didn't get immediately
|
|
|
|
* - extending a lock that's close to timing out
|
|
|
|
*/
|
|
|
|
void afs_lock_work(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct afs_vnode *vnode =
|
|
|
|
container_of(work, struct afs_vnode, lock_work.work);
|
|
|
|
struct key *key;
|
|
|
|
int ret;
|
|
|
|
|
2018-10-20 06:57:57 +07:00
|
|
|
_enter("{%llx:%llu}", vnode->fid.vid, vnode->fid.vnode);
|
2007-07-16 13:40:12 +07:00
|
|
|
|
|
|
|
spin_lock(&vnode->lock);
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
again:
|
|
|
|
_debug("wstate %u for %p", vnode->lock_state, vnode);
|
|
|
|
switch (vnode->lock_state) {
|
|
|
|
case AFS_VNODE_LOCK_NEED_UNLOCK:
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_UNLOCKING);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, NULL, afs_flock_work_unlocking, 0);
|
2007-07-16 13:40:12 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
|
|
|
|
/* attempt to release the server lock; if it fails, we just
|
2017-11-13 23:59:50 +07:00
|
|
|
* wait 5 minutes and it'll expire anyway */
|
|
|
|
ret = afs_release_lock(vnode, vnode->lock_key);
|
2019-04-25 20:26:51 +07:00
|
|
|
if (ret < 0) {
|
|
|
|
trace_afs_flock_ev(vnode, NULL, afs_flock_release_fail,
|
|
|
|
ret);
|
2007-07-16 13:40:12 +07:00
|
|
|
printk(KERN_WARNING "AFS:"
|
2018-10-20 06:57:57 +07:00
|
|
|
" Failed to release lock on {%llx:%llx} error %d\n",
|
2007-07-16 13:40:12 +07:00
|
|
|
vnode->fid.vid, vnode->fid.vnode, ret);
|
2019-04-25 20:26:51 +07:00
|
|
|
}
|
2007-07-16 13:40:12 +07:00
|
|
|
|
|
|
|
spin_lock(&vnode->lock);
|
2019-04-25 20:26:51 +07:00
|
|
|
if (ret == -ENOENT)
|
|
|
|
afs_kill_lockers_enoent(vnode);
|
|
|
|
else
|
|
|
|
afs_next_locker(vnode, 0);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
return;
|
2007-07-16 13:40:12 +07:00
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
/* If we've already got a lock, then it must be time to extend that
|
|
|
|
* lock as AFS locks time out after 5 minutes.
|
|
|
|
*/
|
|
|
|
case AFS_VNODE_LOCK_GRANTED:
|
2007-07-16 13:40:12 +07:00
|
|
|
_debug("extend");
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
ASSERT(!list_empty(&vnode->granted_locks));
|
|
|
|
|
|
|
|
key = key_get(vnode->lock_key);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_EXTENDING);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, NULL, afs_flock_work_extending, 0);
|
2007-07-16 13:40:12 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
ret = afs_extend_lock(vnode, key); /* RPC */
|
2007-07-16 13:40:12 +07:00
|
|
|
key_put(key);
|
2017-11-13 23:59:50 +07:00
|
|
|
|
2019-04-25 20:26:51 +07:00
|
|
|
if (ret < 0) {
|
|
|
|
trace_afs_flock_ev(vnode, NULL, afs_flock_extend_fail,
|
|
|
|
ret);
|
2018-10-20 06:57:57 +07:00
|
|
|
pr_warning("AFS: Failed to extend lock on {%llx:%llx} error %d\n",
|
2017-11-13 23:59:50 +07:00
|
|
|
vnode->fid.vid, vnode->fid.vnode, ret);
|
2019-04-25 20:26:51 +07:00
|
|
|
}
|
2017-11-13 23:59:50 +07:00
|
|
|
|
|
|
|
spin_lock(&vnode->lock);
|
|
|
|
|
2019-04-25 20:26:51 +07:00
|
|
|
if (ret == -ENOENT) {
|
|
|
|
afs_kill_lockers_enoent(vnode);
|
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
if (vnode->lock_state != AFS_VNODE_LOCK_EXTENDING)
|
|
|
|
goto again;
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_GRANTED);
|
2017-11-13 23:59:50 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
if (ret != 0)
|
2007-07-16 13:40:12 +07:00
|
|
|
queue_delayed_work(afs_lock_manager, &vnode->lock_work,
|
|
|
|
HZ * 10);
|
2017-11-13 23:59:50 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
_leave(" [ext]");
|
2007-07-16 13:40:12 +07:00
|
|
|
return;
|
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
/* If we're waiting for a callback to indicate lock release, we can't
|
|
|
|
* actually rely on this, so need to recheck at regular intervals. The
|
|
|
|
* problem is that the server might not notify us if the lock just
|
|
|
|
* expires (say because a client died) rather than being explicitly
|
|
|
|
* released.
|
|
|
|
*/
|
2017-11-13 23:59:50 +07:00
|
|
|
case AFS_VNODE_LOCK_WAITING_FOR_CB:
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
_debug("retry");
|
|
|
|
afs_next_locker(vnode, 0);
|
2007-07-16 13:40:12 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
return;
|
2017-11-13 23:59:50 +07:00
|
|
|
|
2019-04-25 20:26:51 +07:00
|
|
|
case AFS_VNODE_LOCK_DELETED:
|
|
|
|
afs_kill_lockers_enoent(vnode);
|
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
return;
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
default:
|
|
|
|
/* Looks like a lock request was withdrawn. */
|
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
_leave(" [no]");
|
2007-07-16 13:40:12 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* pass responsibility for the unlocking of a vnode on the server to the
|
|
|
|
* manager thread, lest a pending signal in the calling thread interrupt
|
|
|
|
* AF_RXRPC
|
|
|
|
* - the caller must hold the vnode lock
|
|
|
|
*/
|
2017-11-13 23:59:50 +07:00
|
|
|
static void afs_defer_unlock(struct afs_vnode *vnode)
|
2007-07-16 13:40:12 +07:00
|
|
|
{
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
_enter("%u", vnode->lock_state);
|
2017-11-13 23:59:50 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
if (list_empty(&vnode->granted_locks) &&
|
|
|
|
(vnode->lock_state == AFS_VNODE_LOCK_GRANTED ||
|
|
|
|
vnode->lock_state == AFS_VNODE_LOCK_EXTENDING)) {
|
2017-11-13 23:59:50 +07:00
|
|
|
cancel_delayed_work(&vnode->lock_work);
|
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_NEED_UNLOCK);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, NULL, afs_flock_defer_unlock, 0);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
queue_delayed_work(afs_lock_manager, &vnode->lock_work, 0);
|
2017-11-13 23:59:50 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check that our view of the file metadata is up to date and check to see
|
|
|
|
* whether we think that we have a locking permit.
|
|
|
|
*/
|
|
|
|
static int afs_do_setlk_check(struct afs_vnode *vnode, struct key *key,
|
|
|
|
afs_lock_type_t type, bool can_sleep)
|
|
|
|
{
|
|
|
|
afs_access_t access;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* Make sure we've got a callback on this file and that our view of the
|
|
|
|
* data version is up to date.
|
|
|
|
*/
|
|
|
|
ret = afs_validate(vnode, key);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
/* Check the permission set to see if we're actually going to be
|
|
|
|
* allowed to get a lock on this file.
|
|
|
|
*/
|
|
|
|
ret = afs_check_permit(vnode, key, &access);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
/* At a rough estimation, you need LOCK, WRITE or INSERT perm to
|
|
|
|
* read-lock a file and WRITE or INSERT perm to write-lock a file.
|
|
|
|
*
|
|
|
|
* We can't rely on the server to do this for us since if we want to
|
|
|
|
* share a read lock that we already have, we won't go the server.
|
|
|
|
*/
|
|
|
|
if (type == AFS_LOCK_READ) {
|
|
|
|
if (!(access & (AFS_ACE_INSERT | AFS_ACE_WRITE | AFS_ACE_LOCK)))
|
|
|
|
return -EACCES;
|
|
|
|
if (vnode->status.lock_count == -1 && !can_sleep)
|
|
|
|
return -EAGAIN; /* Write locked */
|
|
|
|
} else {
|
|
|
|
if (!(access & (AFS_ACE_INSERT | AFS_ACE_WRITE)))
|
|
|
|
return -EACCES;
|
|
|
|
if (vnode->status.lock_count != 0 && !can_sleep)
|
|
|
|
return -EAGAIN; /* Locked */
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-07-16 13:40:12 +07:00
|
|
|
/*
|
|
|
|
* request a lock on a file on the server
|
|
|
|
*/
|
|
|
|
static int afs_do_setlk(struct file *file, struct file_lock *fl)
|
|
|
|
{
|
2017-11-13 23:59:50 +07:00
|
|
|
struct inode *inode = locks_inode(file);
|
2013-06-21 19:58:15 +07:00
|
|
|
struct afs_vnode *vnode = AFS_FS_I(inode);
|
2007-07-16 13:40:12 +07:00
|
|
|
afs_lock_type_t type;
|
2017-11-02 22:27:52 +07:00
|
|
|
struct key *key = afs_file_key(file);
|
2007-07-16 13:40:12 +07:00
|
|
|
int ret;
|
|
|
|
|
2018-10-20 06:57:57 +07:00
|
|
|
_enter("{%llx:%llu},%u", vnode->fid.vid, vnode->fid.vnode, fl->fl_type);
|
2007-07-16 13:40:12 +07:00
|
|
|
|
|
|
|
fl->fl_ops = &afs_lock_ops;
|
|
|
|
INIT_LIST_HEAD(&fl->fl_u.afs.link);
|
|
|
|
fl->fl_u.afs.state = AFS_LOCK_PENDING;
|
|
|
|
|
|
|
|
type = (fl->fl_type == F_RDLCK) ? AFS_LOCK_READ : AFS_LOCK_WRITE;
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
ret = afs_do_setlk_check(vnode, key, type, fl->fl_flags & FL_SLEEP);
|
2007-07-16 13:40:12 +07:00
|
|
|
if (ret < 0)
|
2017-11-13 23:59:50 +07:00
|
|
|
return ret;
|
2007-07-16 13:40:12 +07:00
|
|
|
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_op(vnode, fl, afs_flock_op_set_lock);
|
|
|
|
|
2007-07-16 13:40:12 +07:00
|
|
|
spin_lock(&vnode->lock);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
list_add_tail(&fl->fl_u.afs.link, &vnode->pending_locks);
|
2007-07-16 13:40:12 +07:00
|
|
|
|
2019-04-25 20:26:51 +07:00
|
|
|
ret = -ENOENT;
|
|
|
|
if (vnode->lock_state == AFS_VNODE_LOCK_DELETED)
|
|
|
|
goto error_unlock;
|
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
/* If we've already got a lock on the server then try to move to having
|
|
|
|
* the VFS grant the requested lock. Note that this means that other
|
|
|
|
* clients may get starved out.
|
2017-11-13 23:59:50 +07:00
|
|
|
*/
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
_debug("try %u", vnode->lock_state);
|
|
|
|
if (vnode->lock_state == AFS_VNODE_LOCK_GRANTED) {
|
|
|
|
if (type == AFS_LOCK_READ) {
|
|
|
|
_debug("instant readlock");
|
|
|
|
list_move_tail(&fl->fl_u.afs.link, &vnode->granted_locks);
|
|
|
|
fl->fl_u.afs.state = AFS_LOCK_GRANTED;
|
|
|
|
goto vnode_is_locked_u;
|
|
|
|
}
|
2007-07-16 13:40:12 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
if (vnode->lock_type == AFS_LOCK_WRITE) {
|
|
|
|
_debug("instant writelock");
|
|
|
|
list_move_tail(&fl->fl_u.afs.link, &vnode->granted_locks);
|
|
|
|
fl->fl_u.afs.state = AFS_LOCK_GRANTED;
|
|
|
|
goto vnode_is_locked_u;
|
|
|
|
}
|
|
|
|
}
|
2007-07-16 13:40:12 +07:00
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
if (vnode->lock_state != AFS_VNODE_LOCK_NONE)
|
|
|
|
goto need_to_wait;
|
2007-07-16 13:40:12 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
try_to_lock:
|
2017-11-13 23:59:50 +07:00
|
|
|
/* We don't have a lock on this vnode and we aren't currently waiting
|
|
|
|
* for one either, so ask the server for a lock.
|
|
|
|
*
|
|
|
|
* Note that we need to be careful if we get interrupted by a signal
|
|
|
|
* after dispatching the request as we may still get the lock, even
|
|
|
|
* though we don't wait for the reply (it's not too bad a problem - the
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
* lock will expire in 5 mins anyway).
|
2017-11-13 23:59:50 +07:00
|
|
|
*/
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, fl, afs_flock_try_to_lock, 0);
|
2017-11-13 23:59:50 +07:00
|
|
|
vnode->lock_key = key_get(key);
|
|
|
|
vnode->lock_type = type;
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_SETTING);
|
2007-07-16 13:40:12 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
ret = afs_set_lock(vnode, key, type); /* RPC */
|
2007-07-16 13:40:12 +07:00
|
|
|
|
|
|
|
spin_lock(&vnode->lock);
|
2017-11-13 23:59:50 +07:00
|
|
|
switch (ret) {
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
case -EKEYREJECTED:
|
|
|
|
case -EKEYEXPIRED:
|
|
|
|
case -EKEYREVOKED:
|
|
|
|
case -EPERM:
|
|
|
|
case -EACCES:
|
|
|
|
fl->fl_u.afs.state = ret;
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, fl, afs_flock_fail_perm, ret);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
list_del_init(&fl->fl_u.afs.link);
|
|
|
|
afs_next_locker(vnode, ret);
|
|
|
|
goto error_unlock;
|
|
|
|
|
2019-04-25 20:26:51 +07:00
|
|
|
case -ENOENT:
|
|
|
|
fl->fl_u.afs.state = ret;
|
|
|
|
trace_afs_flock_ev(vnode, fl, afs_flock_fail_other, ret);
|
|
|
|
list_del_init(&fl->fl_u.afs.link);
|
|
|
|
afs_kill_lockers_enoent(vnode);
|
|
|
|
goto error_unlock;
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
default:
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
fl->fl_u.afs.state = ret;
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, fl, afs_flock_fail_other, ret);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
list_del_init(&fl->fl_u.afs.link);
|
|
|
|
afs_next_locker(vnode, 0);
|
|
|
|
goto error_unlock;
|
2007-07-16 13:40:12 +07:00
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
case -EWOULDBLOCK:
|
|
|
|
/* The server doesn't have a lock-waiting queue, so the client
|
|
|
|
* will have to retry. The server will break the outstanding
|
|
|
|
* callbacks on a file when a lock is released.
|
|
|
|
*/
|
|
|
|
ASSERT(list_empty(&vnode->granted_locks));
|
|
|
|
ASSERTCMP(vnode->pending_locks.next, ==, &fl->fl_u.afs.link);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
goto lock_is_contended;
|
2017-11-13 23:59:50 +07:00
|
|
|
|
|
|
|
case 0:
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_GRANTED);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, fl, afs_flock_acquired, type);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
afs_grant_locks(vnode);
|
|
|
|
goto vnode_is_locked_u;
|
2007-07-16 13:40:12 +07:00
|
|
|
}
|
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
vnode_is_locked_u:
|
2017-11-13 23:59:50 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
vnode_is_locked:
|
|
|
|
/* the lock has been granted by the server... */
|
|
|
|
ASSERTCMP(fl->fl_u.afs.state, ==, AFS_LOCK_GRANTED);
|
2017-11-13 23:59:50 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
/* ... but the VFS still needs to distribute access on this client. */
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, fl, afs_flock_vfs_locking, 0);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
ret = locks_lock_file_wait(file, fl);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, fl, afs_flock_vfs_lock, ret);
|
2007-07-16 13:40:12 +07:00
|
|
|
if (ret < 0)
|
|
|
|
goto vfs_rejected_lock;
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
/* Again, make sure we've got a callback on this file and, again, make
|
2007-07-16 13:40:12 +07:00
|
|
|
* sure that our view of the data version is up to date (we ignore
|
2017-11-13 23:59:50 +07:00
|
|
|
* errors incurred here and deal with the consequences elsewhere).
|
|
|
|
*/
|
afs: Overhaul volume and server record caching and fileserver rotation
The current code assumes that volumes and servers are per-cell and are
never shared, but this is not enforced, and, indeed, public cells do exist
that are aliases of each other. Further, an organisation can, say, set up
a public cell and a private cell with overlapping, but not identical, sets
of servers. The difference is purely in the database attached to the VL
servers.
The current code will malfunction if it sees a server in two cells as it
assumes global address -> server record mappings and that each server is in
just one cell.
Further, each server may have multiple addresses - and may have addresses
of different families (IPv4 and IPv6, say).
To this end, the following structural changes are made:
(1) Server record management is overhauled:
(a) Server records are made independent of cell. The namespace keeps
track of them, volume records have lists of them and each vnode
has a server on which its callback interest currently resides.
(b) The cell record no longer keeps a list of servers known to be in
that cell.
(c) The server records are now kept in a flat list because there's no
single address to sort on.
(d) Server records are now keyed by their UUID within the namespace.
(e) The addresses for a server are obtained with the VL.GetAddrsU
rather than with VL.GetEntryByName, using the server's UUID as a
parameter.
(f) Cached server records are garbage collected after a period of
non-use and are counted out of existence before purging is allowed
to complete. This protects the work functions against rmmod.
(g) The servers list is now in /proc/fs/afs/servers.
(2) Volume record management is overhauled:
(a) An RCU-replaceable server list is introduced. This tracks both
servers and their coresponding callback interests.
(b) The superblock is now keyed on cell record and numeric volume ID.
(c) The volume record is now tied to the superblock which mounts it,
and is activated when mounted and deactivated when unmounted.
This makes it easier to handle the cache cookie without causing a
double-use in fscache.
(d) The volume record is loaded from the VLDB using VL.GetEntryByNameU
to get the server UUID list.
(e) The volume name is updated if it is seen to have changed when the
volume is updated (the update is keyed on the volume ID).
(3) The vlocation record is got rid of and VLDB records are no longer
cached. Sufficient information is stored in the volume record, though
an update to a volume record is now no longer shared between related
volumes (volumes come in bundles of three: R/W, R/O and backup).
and the following procedural changes are made:
(1) The fileserver cursor introduced previously is now fleshed out and
used to iterate over fileservers and their addresses.
(2) Volume status is checked during iteration, and the server list is
replaced if a change is detected.
(3) Server status is checked during iteration, and the address list is
replaced if a change is detected.
(4) The abort code is saved into the address list cursor and -ECONNABORTED
returned in afs_make_call() if a remote abort happened rather than
translating the abort into an error message. This allows actions to
be taken depending on the abort code more easily.
(a) If a VMOVED abort is seen then this is handled by rechecking the
volume and restarting the iteration.
(b) If a VBUSY, VRESTARTING or VSALVAGING abort is seen then this is
handled by sleeping for a short period and retrying and/or trying
other servers that might serve that volume. A message is also
displayed once until the condition has cleared.
(c) If a VOFFLINE abort is seen, then this is handled as VBUSY for the
moment.
(d) If a VNOVOL abort is seen, the volume is rechecked in the VLDB to
see if it has been deleted; if not, the fileserver is probably
indicating that the volume couldn't be attached and needs
salvaging.
(e) If statfs() sees one of these aborts, it does not sleep, but
rather returns an error, so as not to block the umount program.
(5) The fileserver iteration functions in vnode.c are now merged into
their callers and more heavily macroised around the cursor. vnode.c
is removed.
(6) Operations on a particular vnode are serialised on that vnode because
the server will lock that vnode whilst it operates on it, so a second
op sent will just have to wait.
(7) Fileservers are probed with FS.GetCapabilities before being used.
This is where service upgrade will be done.
(8) A callback interest on a fileserver is set up before an FS operation
is performed and passed through to afs_make_call() so that it can be
set on the vnode if the operation returns a callback. The callback
interest is passed through to afs_iget() also so that it can be set
there too.
In general, record updating is done on an as-needed basis when we try to
access servers, volumes or vnodes rather than offloading it to work items
and special threads.
Notes:
(1) Pre AFS-3.4 servers are no longer supported, though this can be added
back if necessary (AFS-3.4 was released in 1998).
(2) VBUSY is retried forever for the moment at intervals of 1s.
(3) /proc/fs/afs/<cell>/servers no longer exists.
Signed-off-by: David Howells <dhowells@redhat.com>
2017-11-02 22:27:50 +07:00
|
|
|
afs_validate(vnode, key);
|
2017-11-13 23:59:50 +07:00
|
|
|
_leave(" = 0");
|
|
|
|
return 0;
|
2007-07-16 13:40:12 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
lock_is_contended:
|
|
|
|
if (!(fl->fl_flags & FL_SLEEP)) {
|
|
|
|
list_del_init(&fl->fl_u.afs.link);
|
|
|
|
afs_next_locker(vnode, 0);
|
|
|
|
ret = -EAGAIN;
|
|
|
|
goto error_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_WAITING_FOR_CB);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, fl, afs_flock_would_block, ret);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
queue_delayed_work(afs_lock_manager, &vnode->lock_work, HZ * 5);
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
need_to_wait:
|
|
|
|
/* We're going to have to wait. Either this client doesn't have a lock
|
|
|
|
* on the server yet and we need to wait for a callback to occur, or
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
* the client does have a lock on the server, but it's shared and we
|
|
|
|
* need an exclusive lock.
|
2017-11-13 23:59:50 +07:00
|
|
|
*/
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
2017-11-13 23:59:50 +07:00
|
|
|
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, fl, afs_flock_waiting, 0);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
ret = wait_event_interruptible(fl->fl_wait,
|
|
|
|
fl->fl_u.afs.state != AFS_LOCK_PENDING);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_ev(vnode, fl, afs_flock_waited, ret);
|
2017-11-13 23:59:50 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
if (fl->fl_u.afs.state >= 0 && fl->fl_u.afs.state != AFS_LOCK_GRANTED) {
|
2017-11-13 23:59:50 +07:00
|
|
|
spin_lock(&vnode->lock);
|
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
switch (fl->fl_u.afs.state) {
|
|
|
|
case AFS_LOCK_YOUR_TRY:
|
|
|
|
fl->fl_u.afs.state = AFS_LOCK_PENDING;
|
|
|
|
goto try_to_lock;
|
|
|
|
case AFS_LOCK_PENDING:
|
|
|
|
if (ret > 0) {
|
|
|
|
/* We need to retry the lock. We may not be
|
|
|
|
* notified by the server if it just expired
|
|
|
|
* rather than being released.
|
|
|
|
*/
|
|
|
|
ASSERTCMP(vnode->lock_state, ==, AFS_VNODE_LOCK_WAITING_FOR_CB);
|
|
|
|
afs_set_lock_state(vnode, AFS_VNODE_LOCK_SETTING);
|
|
|
|
fl->fl_u.afs.state = AFS_LOCK_PENDING;
|
|
|
|
goto try_to_lock;
|
|
|
|
}
|
|
|
|
goto error_unlock;
|
|
|
|
case AFS_LOCK_GRANTED:
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2017-11-13 23:59:50 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
}
|
2017-11-13 23:59:50 +07:00
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
if (fl->fl_u.afs.state == AFS_LOCK_GRANTED)
|
|
|
|
goto vnode_is_locked;
|
|
|
|
ret = fl->fl_u.afs.state;
|
|
|
|
goto error;
|
2007-07-16 13:40:12 +07:00
|
|
|
|
|
|
|
vfs_rejected_lock:
|
2017-11-13 23:59:50 +07:00
|
|
|
/* The VFS rejected the lock we just obtained, so we have to discard
|
|
|
|
* what we just got. We defer this to the lock manager work item to
|
|
|
|
* deal with.
|
|
|
|
*/
|
2007-07-16 13:40:12 +07:00
|
|
|
_debug("vfs refused %d", ret);
|
2017-11-13 23:59:50 +07:00
|
|
|
spin_lock(&vnode->lock);
|
2007-07-16 13:40:12 +07:00
|
|
|
list_del_init(&fl->fl_u.afs.link);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
afs_defer_unlock(vnode);
|
|
|
|
|
|
|
|
error_unlock:
|
|
|
|
spin_unlock(&vnode->lock);
|
|
|
|
error:
|
|
|
|
_leave(" = %d", ret);
|
|
|
|
return ret;
|
2007-07-16 13:40:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* unlock on a file on the server
|
|
|
|
*/
|
|
|
|
static int afs_do_unlk(struct file *file, struct file_lock *fl)
|
|
|
|
{
|
2017-11-13 23:59:50 +07:00
|
|
|
struct afs_vnode *vnode = AFS_FS_I(locks_inode(file));
|
2007-07-16 13:40:12 +07:00
|
|
|
int ret;
|
|
|
|
|
2018-10-20 06:57:57 +07:00
|
|
|
_enter("{%llx:%llu},%u", vnode->fid.vid, vnode->fid.vnode, fl->fl_type);
|
2007-07-16 13:40:12 +07:00
|
|
|
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_op(vnode, fl, afs_flock_op_unlock);
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
/* Flush all pending writes before doing anything with locks. */
|
|
|
|
vfs_fsync(file, 0);
|
|
|
|
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
ret = locks_lock_file_wait(file, fl);
|
2017-11-13 23:59:50 +07:00
|
|
|
_leave(" = %d [%u]", ret, vnode->lock_state);
|
|
|
|
return ret;
|
2007-07-16 13:40:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* return information about a lock we currently hold, if indeed we hold one
|
|
|
|
*/
|
|
|
|
static int afs_do_getlk(struct file *file, struct file_lock *fl)
|
|
|
|
{
|
2017-11-13 23:59:50 +07:00
|
|
|
struct afs_vnode *vnode = AFS_FS_I(locks_inode(file));
|
2017-11-02 22:27:52 +07:00
|
|
|
struct key *key = afs_file_key(file);
|
2007-07-16 13:40:12 +07:00
|
|
|
int ret, lock_count;
|
|
|
|
|
|
|
|
_enter("");
|
|
|
|
|
2019-04-25 20:26:51 +07:00
|
|
|
if (vnode->lock_state == AFS_VNODE_LOCK_DELETED)
|
|
|
|
return -ENOENT;
|
|
|
|
|
2007-07-16 13:40:12 +07:00
|
|
|
fl->fl_type = F_UNLCK;
|
|
|
|
|
|
|
|
/* check local lock records first */
|
2007-07-19 15:50:35 +07:00
|
|
|
posix_test_lock(file, fl);
|
|
|
|
if (fl->fl_type == F_UNLCK) {
|
2007-07-16 13:40:12 +07:00
|
|
|
/* no local locks; consult the server */
|
2018-04-06 20:17:24 +07:00
|
|
|
ret = afs_fetch_status(vnode, key, false);
|
2007-07-16 13:40:12 +07:00
|
|
|
if (ret < 0)
|
|
|
|
goto error;
|
2017-11-13 23:59:50 +07:00
|
|
|
|
|
|
|
lock_count = READ_ONCE(vnode->status.lock_count);
|
2019-04-25 20:26:50 +07:00
|
|
|
if (lock_count != 0) {
|
|
|
|
if (lock_count > 0)
|
|
|
|
fl->fl_type = F_RDLCK;
|
|
|
|
else
|
|
|
|
fl->fl_type = F_WRLCK;
|
|
|
|
fl->fl_start = 0;
|
|
|
|
fl->fl_end = OFFSET_MAX;
|
|
|
|
fl->fl_pid = 0;
|
|
|
|
}
|
2007-07-16 13:40:12 +07:00
|
|
|
}
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
ret = 0;
|
2007-07-16 13:40:12 +07:00
|
|
|
error:
|
|
|
|
_leave(" = %d [%hd]", ret, fl->fl_type);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* manage POSIX locks on a file
|
|
|
|
*/
|
|
|
|
int afs_lock(struct file *file, int cmd, struct file_lock *fl)
|
|
|
|
{
|
2017-11-13 23:59:50 +07:00
|
|
|
struct afs_vnode *vnode = AFS_FS_I(locks_inode(file));
|
2019-04-25 20:26:50 +07:00
|
|
|
enum afs_flock_operation op;
|
|
|
|
int ret;
|
2007-07-16 13:40:12 +07:00
|
|
|
|
2018-10-20 06:57:57 +07:00
|
|
|
_enter("{%llx:%llu},%d,{t=%x,fl=%x,r=%Ld:%Ld}",
|
2007-07-16 13:40:12 +07:00
|
|
|
vnode->fid.vid, vnode->fid.vnode, cmd,
|
|
|
|
fl->fl_type, fl->fl_flags,
|
|
|
|
(long long) fl->fl_start, (long long) fl->fl_end);
|
|
|
|
|
|
|
|
/* AFS doesn't support mandatory locks */
|
2007-10-02 04:41:14 +07:00
|
|
|
if (__mandatory_lock(&vnode->vfs_inode) && fl->fl_type != F_UNLCK)
|
2007-07-16 13:40:12 +07:00
|
|
|
return -ENOLCK;
|
|
|
|
|
|
|
|
if (IS_GETLK(cmd))
|
|
|
|
return afs_do_getlk(file, fl);
|
2019-04-25 20:26:50 +07:00
|
|
|
|
|
|
|
fl->fl_u.afs.debug_id = atomic_inc_return(&afs_file_lock_debug_id);
|
|
|
|
trace_afs_flock_op(vnode, fl, afs_flock_op_lock);
|
|
|
|
|
2007-07-16 13:40:12 +07:00
|
|
|
if (fl->fl_type == F_UNLCK)
|
2019-04-25 20:26:50 +07:00
|
|
|
ret = afs_do_unlk(file, fl);
|
|
|
|
else
|
|
|
|
ret = afs_do_setlk(file, fl);
|
|
|
|
|
|
|
|
switch (ret) {
|
|
|
|
case 0: op = afs_flock_op_return_ok; break;
|
|
|
|
case -EAGAIN: op = afs_flock_op_return_eagain; break;
|
|
|
|
case -EDEADLK: op = afs_flock_op_return_edeadlk; break;
|
|
|
|
default: op = afs_flock_op_return_error; break;
|
|
|
|
}
|
|
|
|
trace_afs_flock_op(vnode, fl, op);
|
|
|
|
return ret;
|
2007-07-16 13:40:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* manage FLOCK locks on a file
|
|
|
|
*/
|
|
|
|
int afs_flock(struct file *file, int cmd, struct file_lock *fl)
|
|
|
|
{
|
2017-11-13 23:59:50 +07:00
|
|
|
struct afs_vnode *vnode = AFS_FS_I(locks_inode(file));
|
2019-04-25 20:26:50 +07:00
|
|
|
enum afs_flock_operation op;
|
|
|
|
int ret;
|
2007-07-16 13:40:12 +07:00
|
|
|
|
2018-10-20 06:57:57 +07:00
|
|
|
_enter("{%llx:%llu},%d,{t=%x,fl=%x}",
|
2007-07-16 13:40:12 +07:00
|
|
|
vnode->fid.vid, vnode->fid.vnode, cmd,
|
|
|
|
fl->fl_type, fl->fl_flags);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* No BSD flocks over NFS allowed.
|
|
|
|
* Note: we could try to fake a POSIX lock request here by
|
|
|
|
* using ((u32) filp | 0x80000000) or some such as the pid.
|
|
|
|
* Not sure whether that would be unique, though, or whether
|
|
|
|
* that would break in other places.
|
|
|
|
*/
|
|
|
|
if (!(fl->fl_flags & FL_FLOCK))
|
|
|
|
return -ENOLCK;
|
|
|
|
|
2019-04-25 20:26:50 +07:00
|
|
|
fl->fl_u.afs.debug_id = atomic_inc_return(&afs_file_lock_debug_id);
|
|
|
|
trace_afs_flock_op(vnode, fl, afs_flock_op_flock);
|
|
|
|
|
2007-07-16 13:40:12 +07:00
|
|
|
/* we're simulating flock() locks using posix locks on the server */
|
|
|
|
if (fl->fl_type == F_UNLCK)
|
2019-04-25 20:26:50 +07:00
|
|
|
ret = afs_do_unlk(file, fl);
|
|
|
|
else
|
|
|
|
ret = afs_do_setlk(file, fl);
|
|
|
|
|
|
|
|
switch (ret) {
|
|
|
|
case 0: op = afs_flock_op_return_ok; break;
|
|
|
|
case -EAGAIN: op = afs_flock_op_return_eagain; break;
|
|
|
|
case -EDEADLK: op = afs_flock_op_return_edeadlk; break;
|
|
|
|
default: op = afs_flock_op_return_error; break;
|
|
|
|
}
|
|
|
|
trace_afs_flock_op(vnode, fl, op);
|
|
|
|
return ret;
|
2007-07-16 13:40:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* the POSIX lock management core VFS code copies the lock record and adds the
|
|
|
|
* copy into its own list, so we need to add that copy to the vnode's lock
|
|
|
|
* queue in the same place as the original (which will be deleted shortly
|
|
|
|
* after)
|
|
|
|
*/
|
|
|
|
static void afs_fl_copy_lock(struct file_lock *new, struct file_lock *fl)
|
|
|
|
{
|
2017-11-13 23:59:50 +07:00
|
|
|
struct afs_vnode *vnode = AFS_FS_I(locks_inode(fl->fl_file));
|
|
|
|
|
2007-07-16 13:40:12 +07:00
|
|
|
_enter("");
|
|
|
|
|
2019-04-25 20:26:50 +07:00
|
|
|
new->fl_u.afs.debug_id = atomic_inc_return(&afs_file_lock_debug_id);
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
spin_lock(&vnode->lock);
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_op(vnode, new, afs_flock_op_copy_lock);
|
2007-07-16 13:40:12 +07:00
|
|
|
list_add(&new->fl_u.afs.link, &fl->fl_u.afs.link);
|
2017-11-13 23:59:50 +07:00
|
|
|
spin_unlock(&vnode->lock);
|
2007-07-16 13:40:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* need to remove this lock from the vnode queue when it's removed from the
|
|
|
|
* VFS's list
|
|
|
|
*/
|
|
|
|
static void afs_fl_release_private(struct file_lock *fl)
|
|
|
|
{
|
2017-11-13 23:59:50 +07:00
|
|
|
struct afs_vnode *vnode = AFS_FS_I(locks_inode(fl->fl_file));
|
|
|
|
|
2007-07-16 13:40:12 +07:00
|
|
|
_enter("");
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
spin_lock(&vnode->lock);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
|
2019-04-25 20:26:50 +07:00
|
|
|
trace_afs_flock_op(vnode, fl, afs_flock_op_release_lock);
|
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>
2019-04-25 20:26:50 +07:00
|
|
|
list_del_init(&fl->fl_u.afs.link);
|
|
|
|
if (list_empty(&vnode->granted_locks))
|
|
|
|
afs_defer_unlock(vnode);
|
|
|
|
|
2017-11-13 23:59:50 +07:00
|
|
|
_debug("state %u for %p", vnode->lock_state, vnode);
|
|
|
|
spin_unlock(&vnode->lock);
|
2007-07-16 13:40:12 +07:00
|
|
|
}
|