Vendredi 09 avril 2010, vers 15:05:14 (+0200), j'ai écrit : > 1. opens a first file, and acquires read lock on it ; > 2. opens a second file, and acquires read lock on it ; > 3. releases locks, and closes files. > > Both opened files are of course on the NFS mount. On the first run, all > seems to be fine. On the second (and subsequent) runs, the lock is > refused at step 2 with errno=37 (ENOLCK, No locks available). I noticed that things appear to work as expected if commit 8e469ebd6dc32cbaf620e134d79f740bf0ebab79 (NFSv4: Don't allow posix locking against servers that don't support it) is reverted. >From what I can see, the client is granted a read delegation for the second file. On the second run, the client fetches some cached state for this file. On this second run, state->flags (as in _nfs4_do_open, or in nfs4_proc_lock) only contains NFS_DELEGATED_STATE, while on the first run, it also contained NFS_O_RDONLY_STATE and NFS_STATE_POSIX_LOCKS. Then, I do not fully understand the code, and I am not able to suggest any satisfying patch to correct the problem. Regards, Arnaud Giersch -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html