1. 06 2月, 2007 5 次提交
    • D
      [DLM] rename dlm_config_info fields · 68c817a1
      David Teigland 提交于
      Add a "ci_" prefix to the fields in the dlm_config_info struct so that we
      can use macros to add configfs functions to access them (in a later
      patch).  No functional changes in this patch, just naming changes.
      Signed-off-by: NDavid Teigland <teigland@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      68c817a1
    • D
      [DLM] fix lost flags in stub replies · 075529b5
      David Teigland 提交于
      When the dlm fakes an unlock/cancel reply from a failed node using a stub
      message struct, it wasn't setting the flags in the stub message.  So, in
      the process of receiving the fake message the lkb flags would be updated
      and cleared from the zero flags in the message.  The problem observed in
      tests was the loss of the USER flag which caused the dlm to think a user
      lock was a kernel lock and subsequently fail an assertion checking the
      validity of the ast/callback field.
      Signed-off-by: NDavid Teigland <teigland@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      075529b5
    • D
      [DLM] fix receive_request() lvb copying · 8d07fd50
      David Teigland 提交于
      LVB's are not sent as part of new requests, but the code receiving the
      request was copying data into the lvb anyway.  The space in the message
      where it mistakenly thought the lvb lived actually contained the resource
      name, so it wound up incorrectly copying this name data into the lvb.  Fix
      is to just create the lvb, not copy junk into it.
      Signed-off-by: NDavid Teigland <teigland@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      8d07fd50
    • D
      [DLM] fix send_args() lvb copying · da49f36f
      David Teigland 提交于
      The send_args() function is used to copy parameters into a message for a
      number different message types.  Only some of those types are set up
      beforehand (in create_message) to include space for sending lvb data.
      send_args was wrongly copying the lvb for all message types as long as the
      lock had an lvb.  This means that the lvb data was being written past the
      end of the message into unknown space.
      Signed-off-by: NDavid Teigland <teigland@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      da49f36f
    • D
      [DLM] fix resend rcom lock · dc200a88
      David Teigland 提交于
      There's a chance the new master of resource hasn't learned it's the new
      master before another node sends it a lock during recovery.  The node
      sending the lock needs to resend if this happens.
      
      - A sends a master lookup for resource R to C
      - B sends a master lookup for resource R to C
      - C receives A's lookup, assigns A to be master of R and
        sends a reply back to A
      - C receives B's lookup and sends a reply back to B saying
        that A is the master
      - B receives lookup reply from C and sends its lock for R to A
      - A receives lock from B, doesn't think it's the master of R
        and sends an error back to B
      - A receives lookup reply from C and becomes master of R
      - B gets error back from A and resends its lock back to A
        (this resending is what this patch does)
      - A receives lock from B, it now sees it's the master of R
        and takes the lock
      Signed-off-by: NDavid Teigland <teigland@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      dc200a88
  2. 30 11月, 2006 2 次提交
    • D
      [DLM] clear sbflags on lock master · 6f90a8b1
      David Teigland 提交于
      RH BZ 211622
      
      The ALTMODE flag can be set in the lock master's copy of the lock but
      never cleared, so ALTMODE will also be returned in a subsequent conversion
      of the lock when it shouldn't be.  This results in lock_dlm incorrectly
      switching to the alternate lock mode when returning the result to gfs
      which then asserts when it sees the wrong lock state.  The fix is to
      propagate the cleared sbflags value to the master node when the lock is
      requested.  QA's d_rwrandirectlarge test triggers this bug very quickly.
      Signed-off-by: NDavid Teigland <teigland@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      6f90a8b1
    • D
      [DLM] fix requestqueue race · d4400156
      David Teigland 提交于
      Red Hat BZ 211914
      
      There's a race between dlm_recoverd (1) enabling locking and (2) clearing
      out the requestqueue, and dlm_recvd (1) checking if locking is enabled and
      (2) adding a message to the requestqueue.  An order of recoverd(1),
      recvd(1), recvd(2), recoverd(2) will result in a message being left on the
      requestqueue.  The fix is to have dlm_recvd check if dlm_recoverd has
      enabled locking after taking the mutex for the requestqueue and if it has
      processing the message instead of queueing it.
      Signed-off-by: NDavid Teigland <teigland@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      d4400156
  3. 25 9月, 2006 1 次提交
  4. 09 9月, 2006 1 次提交
    • D
      [DLM] confirm master for recovered waiting requests · fa9f0e49
      David Teigland 提交于
      Fixing the following scenario:
      - A request is on the waiters list waiting for a reply from a remote node.
      - The request is the first one on the resource, so first_lkid is set.
      - The remote node fails causing recovery.
      - During recovery the requesting node becomes master.
      - The request is now processed locally instead of being a remote operation.
      - At this point we need to call confirm_master() on the resource since
        we're certain we're now the master node.  This will clear first_lkid.
      - We weren't calling confirm_master(), so first_lkid was not being cleared
        causing subsequent requests on that resource to get stuck.
      Signed-off-by: NDavid Teigland <teigland@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      fa9f0e49
  5. 24 8月, 2006 1 次提交
  6. 23 8月, 2006 2 次提交
  7. 21 8月, 2006 1 次提交
  8. 08 8月, 2006 1 次提交
  9. 26 7月, 2006 2 次提交
  10. 20 7月, 2006 2 次提交
  11. 13 7月, 2006 1 次提交
  12. 03 5月, 2006 1 次提交
  13. 01 3月, 2006 1 次提交
  14. 23 2月, 2006 1 次提交
  15. 20 1月, 2006 1 次提交
  16. 18 1月, 2006 1 次提交