posix record locking?

DISCUSSION moiz kohari 2 participants 2 messages Nov 25, 2003 – Nov 26, 2003

Subsystems (2)

NFS client NFS server

lore

Share & tools

lore

moiz kohari

author

2003-11-25 00:24 UTC #0 lore raw

Hi,

I am looking at posix record locking with nfs and I have a couple of questions:

1. The fcntl_setlk() calls nfs_lock() (towards the end of fcntl_setlk by calling filp->f_op->lock), fcntl_setlk() then calls posix_lock_file() (where all the vfs magic happens for file locks). If nfs_lock() returns successful (server has granted the lock) but the subsequent posix_lock_file() fails (due to deadlock, conflict or low memory), we never go back to the server to clean up this lock. Is this a problem or am I missing something?

2. nfs_lock() calls nlmclnt_proc() after we pick up the kernel lock (lock_kernel()). The nlmclnt_proc() goes on to call:
nlmclnt_lock()
nlmclnt_call()
rpc...

Is this OK? Are we going over the wire while holding the kernel lock?

Thanks for your help and please cc my email on any responses.

Best Regards,

Moiz

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Trond Myklebust

2003-11-26 00:50 UTC #1 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == moiz kohari <[email protected]> writes:

> Hi, I am looking at posix record locking with nfs and I have a > couple of questions:

> 1. The fcntl_setlk() calls nfs_lock() (towards the end of fcntl_setlk
> by calling filp->f_op->lock), fcntl_setlk() then calls
> posix_lock_file() (where all the vfs magic happens for file
> locks). If nfs_lock() returns successful (server has
> granted the lock) but the subsequent posix_lock_file() fails
> (due to deadlock, conflict or low memory), we never go back
> to the server to clean up this lock. Is this a problem or
> am I missing something?

Low memory is a problem, but how are you going to solve that (RPC calls require memory too)?

As for the rest: why would the VFS tell us we're deadlocked/conflicting if the server says we aren't? That would clearly be a bug.

> 2. nfs_lock() calls nlmclnt_proc() after we pick up the kernel lock
> (lock_kernel()). The nlmclnt_proc() goes on to call:

> nlmclnt_lock() nlmclnt_call() rpc...

> Is this OK? Are we going over the wire while holding the > kernel lock?

Yes. The BKL is unique as far as spinlocks go in that it allows this sort of thing.

Cheers,
Trond