Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-13115

always check object existence after mo_xattr_get()


    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Lustre 2.14.0
    • Labels:
    • Severity:
    • Rank (Obsolete):


      There is specific case with lu_object LOHA_EXISTS flag in DNE environment when it can be dropped if remote object was found non-existent (deleted most likely?) which may cause problems in current MDT code paths.

      Without DNE LOHA_EXISTS is never dropped being set, when object is deleted it is just marked as destroyed (by LU_OBJECT_HEARD_BANSHEE flag). Therefore object being once checked for existence is always 'exists' in rest of code at least until lu_object_put() and requires no extra checks with lu_object_exists()

      With DNE the LOHA_EXISTS flag can be dropped during osp_xattr_get(). I am not sure if that was right decision, probably we have to keep the same semantic and keep LOHA_EXISTS always but just mark object as non-existent remotely, or use LU_OBJECT_HEARD_BANSHEE also like for local objects. Anyway, with DNE it is possible that existent object can become non-existent after mo_xattr_get() call. Therefore a return code of mo_xattr_get() must always be handled and checked for -ENOENT or lu_object_exists() must be performed right after that call.

      The mdt_pack_secctx_in_reply() ignores all return code silently and that opens door for lu_object_exists() assertions in further code path. While this function is about the optional XATTR getting it is still important to check -ENOENT case because it might change object state.

      Also there can be other places in code where result of mo_xattr_get() is not handled and this remains obscured for code writers. I wonder how to make people know about that mo_xattr_get() specific, probably osp_xattr_get() should be revised to don't drop LOHA_EXISTS flag but mark object as non-existent remotely.


          Issue Links



              • Assignee:
                tappro Mikhail Pershin
                tappro Mikhail Pershin
              • Votes:
                0 Vote for this issue
                5 Start watching this issue


                • Created: