1. 29 Oct, 2020 1 commit
  2. 19 Sep, 2020 3 commits
  3. 27 May, 2020 1 commit
  4. 23 Apr, 2020 1 commit
  5. 15 Apr, 2020 1 commit
  6. 14 Apr, 2020 1 commit
  7. 11 Mar, 2020 1 commit
  8. 05 Mar, 2020 1 commit
  9. 01 Mar, 2020 1 commit
  10. 25 Feb, 2020 1 commit
  11. 08 Feb, 2020 1 commit
  12. 28 Jan, 2020 1 commit
  13. 10 Jan, 2020 2 commits
    • NeilBrown's avatar
      LU-12542 handle: rename ops to owner · 1a9aafbf
      NeilBrown authored
      
      
      Now that portals_handle_ops contains only a char*,
      it is functioning primarily to identify the owner of each handle.
      So change the name to h_owner, and the type to const char*.
      
      Note: this h_owner is now quite different from the similar h_owner
      in the server code.  When server code it merged the
      "med" pointer should be stored in the "mfd" and validated separately.
      
      Change-Id: Ie2e9134ea22c4929683c84bf45c41b96b348d0a2
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Reviewed-on: https://review.whamcloud.com/35798
      
      
      Reviewed-by: default avatarShaun Tancheff <stancheff@cray.com>
      Tested-by: default avatarjenkins <devops@whamcloud.com>
      Tested-by: default avatarMaloo <maloo@whamcloud.com>
      Reviewed-by: default avatarNeil Brown <neilb@suse.de>
      Reviewed-by: default avatarOleg Drokin <green@whamcloud.com>
      1a9aafbf
    • Mr NeilBrown's avatar
      LU-10467 lustre: use wait_event_idle_timeout() as appropriate. · a7ff5d05
      Mr NeilBrown authored
      If l_wait_event() is passed an lwi initialised with
      one of
         LWI_TIMEOUT_INTR( time, NULL, NULL, NULL)
         LWI_TIMEOUT_INTR( time, NULL, LWI_ON_SIGNAL_NOOP, NULL)
         LWI_TIMEOUT( time, NULL, NULL)
      where time != 0, then it behaves much like
      wait_event_idle_timeout().
      All signals are blocked, and it waits either for the
      condition to be true, or for the timeout (in jiffies).
      
      Note that LWI_ON_SIGNAL_NOOP has no effect here.
      
      l_wait_event() returns 0 when the condition is true, or -ETIMEDOUT
      when the timeout occurs.  wait_event_idle_timeout() instead returns a
      positive number when the condition is true, and 0 when the timeout
      occurs.  So in the cases where return value is used, handling needs to
      be adjusted accordingly.
      
      Note that in some cases where cfs_fail_val gives the time to wait for,
      the current code re-tests the wait time against zero as cfs_fail_val
      can change asynchronously.  This is because l_wait_event() behaves
      quite differently if th...
      a7ff5d05
  14. 20 Dec, 2019 1 commit
  15. 14 Dec, 2019 2 commits
  16. 06 Dec, 2019 4 commits
  17. 04 Oct, 2019 1 commit
  18. 20 Sep, 2019 2 commits
  19. 27 Aug, 2019 1 commit
  20. 15 Aug, 2019 1 commit
    • NeilBrown's avatar
      LU-12542 handles: discard h_owner in favour of h_ops · 9bda0a5c
      NeilBrown authored
      lustre_handles assigned a 64bit unique identifier (a 'cookie') to
      objects of various types and stored them in a hash table, allowing
      them to be accessed by the cookie.
      
      There is a facility for type checking by recording an 'owner' for each
      object, and checking the owner on lookup. Unfortunately this is not
      used - owner is always zero for the client.
      
      Each object also contains an h_ops pointer which can be used to
      reliably identify an owner.
      
      So discard h_owner, pass and 'ops' pointer to class_handle2object(),
      and only return objects for which the h_ops matches.
      
      Note: this h_owner is now quiet different from the similar h_owner
      in the server code.  When the server code is merged the "med" pointer
      should be stored in the "mfd" and validated separately.
      
      This reduces the size of the portals_handle by one pointer, which
      benefits various other structures including struct ldlm_lock which can
      be very populous and so is best keep small.
      
      Change-Id: I9cf2b32f8b...
      9bda0a5c
  21. 03 Jul, 2019 1 commit
  22. 25 Jun, 2019 1 commit
  23. 01 Jun, 2019 1 commit
  24. 21 Mar, 2019 2 commits
  25. 04 Jan, 2019 1 commit
  26. 17 Nov, 2018 1 commit
  27. 23 Oct, 2018 1 commit
  28. 10 Oct, 2018 1 commit
  29. 05 Oct, 2018 1 commit
  30. 18 Aug, 2018 1 commit
  31. 29 May, 2018 1 commit