1. 13 7月, 2014 1 次提交
    • J
      nfs4: treat lock owners as opaque values · 8003d3c4
      Jeff Layton 提交于
      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: NJeff Layton <jlayton@poochiereds.net>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      8003d3c4
  2. 25 6月, 2014 2 次提交
  3. 29 5月, 2014 1 次提交
  4. 20 2月, 2014 2 次提交
  5. 30 1月, 2014 1 次提交
  6. 20 11月, 2013 1 次提交
  7. 29 10月, 2013 7 次提交
  8. 11 9月, 2013 2 次提交
  9. 08 9月, 2013 1 次提交
  10. 05 9月, 2013 4 次提交
  11. 04 9月, 2013 4 次提交
  12. 08 8月, 2013 1 次提交
  13. 09 6月, 2013 1 次提交
  14. 07 6月, 2013 1 次提交
  15. 07 5月, 2013 1 次提交
  16. 20 4月, 2013 1 次提交
  17. 26 3月, 2013 4 次提交
  18. 12 2月, 2013 2 次提交
  19. 06 12月, 2012 3 次提交