J. Bruce Fields [EMAIL PROTECTED] wrote:
Yes. I need to get the server lock first, before going to the VFS locking
routines.
That doesn't really answer the question. The NFS client has similar
requirements, but it doesn't have to duplicate the per-inode lists of
granted locks, for
J. Bruce Fields [EMAIL PROTECTED] wrote:
--without having tried to understand how they're actually used, these
data structures (like the pending_locks and granted_locks lists) seem to
duplicate stuff that's already kept in fs/locks.c. Is there a reason
they're required?
Yes. I need to get
On Wed, May 30, 2007 at 09:35:32AM +0100, David Howells wrote:
J. Bruce Fields [EMAIL PROTECTED] wrote:
--without having tried to understand how they're actually used, these
data structures (like the pending_locks and granted_locks lists) seem to
duplicate stuff that's already kept in
Implement file locking for AFS.
[try #2]:
(*) Start the lock manager thread under a mutex to avoid a race.
(*) Made the locking non-fair: New readlocks will jump pending writelocks if
there's a readlock currently granted on a file. This makes the behaviour
similar to Linux's VFS
One more vague question I had while skimming the previous version--
On Tue, May 29, 2007 at 03:54:27PM +0100, David Howells wrote:
+static void afs_grant_locks(struct afs_vnode *vnode, struct file_lock *fl)
+{
+ struct file_lock *p, *_p;
+
+ list_move_tail(fl-fl_u.afs.link,
