• Jeff Layton's avatar
    nfs4: treat lock owners as opaque values · 8003d3c4
    Jeff Layton authored
    Do the following set of ops with a file on a NFSv4 mount:
    
        exec 3>>/file/on/nfsv4
        flock -x 3
        exec 3>&-
    
    You'll see the LOCK request go across the wire, but no LOCKU when the
    file is closed.
    
    What happens is that the fd is passed across a fork, and the final close
    is done in a different process than the opener. That makes
    __nfs4_find_lock_state miss finding the correct lock state because it
    uses the fl_pid as a search key. A new one is created, and the locking
    code treats it as a delegation stateid (because NFS_LOCK_INITIALIZED
    isn't set).
    
    The root cause of this breakage seems to be commit 77041ed9
    (NFSv4: Ensure the lockowners are labelled using the fl_owner and/or
    fl_pid).
    
    That changed it so that flock lockowners are allocated based on the
    fl_pid. I think this is incorrect. flock locks should be "owned" by the
    struct file, and that is already accounted for in the fl_owner field of
    the lock request when it comes through nfs_flock.
    
    This patch basically reverts the above commit and with it, a LOCKU is
    sent in the above reproducer.
    Signed-off-by: default avatarJeff Layton <jlayton@poochiereds.net>
    Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
    8003d3c4
nfs4_fs.h 17.3 KB