• NeilBrown's avatar
    NFSv4: Don't try to recover NFSv4 locks when they are lost. · ef1820f9
    NeilBrown authored
    When an NFSv4 client loses contact with the server it can lose any
    locks that it holds.
    
    Currently when it reconnects to the server it simply tries to reclaim
    those locks.  This might succeed even though some other client has
    held and released a lock in the mean time.  So the first client might
    think the file is unchanged, but it isn't.  This isn't good.
    
    If, when recovery happens, the locks cannot be claimed because some
    other client still holds the lock, then we get a message in the kernel
    logs, but the client can still write.  So two clients can both think
    they have a lock and can both write at the same time.  This is equally
    not good.
    
    There was a patch a while ago
      http://comments.gmane.org/gmane.linux.nfs/41917
    
    which tried to address some of this, but it didn't seem to go
    anywhere.  That patch would also send a signal to the process.  That
    might be useful but for now this patch just causes writes to fail.
    
    For NFSv4 (unlike v2/v3) there is a strong link between the lock and
    the write request so we can fairly easily fail any IO of the lock is
    gone.  While some applications might not expect this, it is still
    safer than allowing the write to succeed.
    
    Because this is a fairly big change in behaviour a module parameter,
    "recover_locks", is introduced which defaults to true (the current
    behaviour) but can be set to "false" to tell the client not to try to
    recover things that were lost.
    Signed-off-by: default avatarNeilBrown <neilb@suse.de>
    Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
    ef1820f9
nfs4state.c 58.3 KB