1. 04 4月, 2009 17 次提交
  2. 19 3月, 2009 16 次提交
  3. 28 1月, 2009 1 次提交
    • J
      nfsd: only set file_lock.fl_lmops in nfsd4_lockt if a stateowner is found · fa82a491
      Jeff Layton 提交于
      nfsd4_lockt does a search for a lockstateowner when building the lock
      struct to test. If one is found, it'll set fl_owner to it. Regardless of
      whether that happens, it'll also set fl_lmops. Given that this lock is
      basically a "lightweight" lock that's just used for checking conflicts,
      setting fl_lmops is probably not appropriate for it.
      
      This behavior exposed a bug in DLM's GETLK implementation where it
      wasn't clearing out the fields in the file_lock before filling in
      conflicting lock info. While we were able to fix this in DLM, it
      still seems pointless and dangerous to set the fl_lmops this way
      when we may have a NULL lockstateowner.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@pig.fieldses.org>
      fa82a491
  4. 08 1月, 2009 2 次提交
  5. 07 1月, 2009 1 次提交
  6. 24 12月, 2008 2 次提交
  7. 25 11月, 2008 1 次提交