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

ASSERTION( new_lock->l_readers + new_lock->l_writers == 0 ) failed

Details

    • Bug
    • Resolution: Duplicate
    • Critical
    • None
    • None
    • MDS node, Lustre 2.4.2-14chaos, ZFS OBD
    • 3
    • 15383

    Description

      After upgrading to lustre 2.4.2-14chaos (see github.com/chaos/lustre), we soon hit the following assertion on one of our MDS nodes:

      mdt_handler.c:3652:mdt_intent_lock_replace()) ASSERTION( new_lock->l_readers + new_lock->l_writers == 0 ) failed

      Perhaps most significantly, this tag of our lustre tree includes the patch entitled:

      LU-4584 mdt: ensure orig lock is found in hash upon resend

      James Simmons reported this assertion when he tested the LU-4584 patch, but the Bruno made the evaluation that the assertion was unrelated to the patch.

      Whether it is related or not, we need to fix the problem.

      Attachments

        Issue Links

          is related to

          Bug - A problem which impairs or prevents the functions of the product. LU-5632 ldlm_lock_addref()) ASSERTION( lock != ((void *)0) )

          • Major - Major loss of function.
          • Resolved
          is related to

          Bug - A problem which impairs or prevents the functions of the product. LU-4584 Lock revocation process fails consistently

          • Critical - Crashes, loss of data, severe memory leak.
          • Resolved

          Technical task - A technical task. LU-3428 Fix 'uninitialized variables' errors

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Activity

            [LU-5525] ASSERTION( new_lock->l_readers + new_lock->l_writers == 0 ) failed
            adilger Andreas Dilger made changes -
            Resolution New: Duplicate [ 3 ]
            Status Original: Open [ 1 ] New: Resolved [ 5 ]
            adilger Andreas Dilger made changes -
            Link New: This issue is related to LU-3428 [ LU-3428 ]
            pjones Peter Jones made changes -
            End date New: 10/Nov/14
            Start date New: 20/Aug/14
            pjones Peter Jones made changes -
            Labels Original: llnl p4l New: llnl
            pjones Peter Jones made changes -
            Labels Original: llnl p4l topllnl New: llnl p4l
            adilger Andreas Dilger made changes -
            Link New: This issue is related to LU-5632 [ LU-5632 ]
            morrone Christopher Morrone (Inactive) made changes -
            Link New: This issue is related to LU-4584 [ LU-4584 ]
            morrone Christopher Morrone (Inactive) made changes -
            Description Original: After upgrading to lustre 2.4.2-14chaos (see github.com/chaos/lustre), we soon hit the following assertion on one of our MDS nodes:

            {noformat}mdt_handler.c:3652:mdt_intent_lock_replase()) ASSERTION( new_lock->l_readers + new_lock->l_writers == 0 ) failed{noformat}

            Perhaps most significantly, this tag of our lustre tree includes the patch entitled:

            {noformat}LU-4584 mdt: ensure orig lock is found in hash upon resend{noformat}

            James Simmons reported this assertion when he tested the LU-4584 patch, but the Bruno [made the evaluation|https://jira.hpdd.intel.com/browse/LU-4584?focusedCommentId=82590&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-82590] that the assertion was unrelated to the patch.

            Whether it is related or not, we need to fix the problem.             		New: After upgrading to lustre 2.4.2-14chaos (see github.com/chaos/lustre), we soon hit the following assertion on one of our MDS nodes:

            {noformat}mdt_handler.c:3652:mdt_intent_lock_replace()) ASSERTION( new_lock->l_readers + new_lock->l_writers == 0 ) failed{noformat}

            Perhaps most significantly, this tag of our lustre tree includes the patch entitled:

            {noformat}LU-4584 mdt: ensure orig lock is found in hash upon resend{noformat}

            James Simmons reported this assertion when he tested the LU-4584 patch, but the Bruno [made the evaluation|https://jira.hpdd.intel.com/browse/LU-4584?focusedCommentId=82590&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-82590] that the assertion was unrelated to the patch.

            Whether it is related or not, we need to fix the problem.
            pjones Peter Jones made changes -
            Labels Original: llnl topllnl New: llnl p4l topllnl
            pjones Peter Jones made changes -
            Assignee Original: WC Triage [ wc-triage ] New: Bruno Faccini [ bfaccini ]

            People

              bfaccini Bruno Faccini (Inactive)
              morrone Christopher Morrone (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: