1. 08 Aug, 2017 1 commit
  2. 10 Jul, 2016 2 commits
  3. 05 May, 2014 4 commits
    • Dries Kimpe's avatar
      Revert "Fix a race condition which may lead to client hung up." · bc4d389c
      Dries Kimpe authored
      This reverts commit c4ba141e.
      
      Breaks BMI IB.
      bc4d389c
    • Dries Kimpe's avatar
      Revert "Fix potential connection starvation in bmi_ib" · 52c03abd
      Dries Kimpe authored
      This reverts commit 1883ac0f.
      
      One of these patches is causing connection setup to fail with a bad file
      descriptor error.
      52c03abd
    • Zhang Jingwang's avatar
      Fix potential connection starvation in bmi_ib · 1883ac0f
      Zhang Jingwang authored
      The new coming connection are handled in the function
      ib_tcp_server_check_new_connections(); and this is called inside the
      function ib_block_for_activity(). However the ib_block_for_activity()
      is only called when the network is idle in BMI_ib_testcontext() or
      BMI_ib_testunexpected().
      
      As a result, when the server is busy serving one client process, the
      other processes can't make a new connections to the server and thus
      they can't transfer data to the server concurrently.
      
      Change-Id: Ib9c28e0e5c38cf03741c2220a9a95e2c9ffbe5a1
      1883ac0f
    • Zhang Jingwang's avatar
      Fix a race condition which may lead to client hung up. · c4ba141e
      Zhang Jingwang authored
      The correctness of BMI depends on the order of two events: the
      completion event of the work request for the MSG_CTS message, the
      arrival of the message with type MSG_RTS_DONE.
      
      If the MSG_RTS_DONE messages arrives first, then there would be no
      request in the state of RQ_RTS_WAITING_RTS_DONE, so it can't advance
      the state machine. As a result, a log message is printed and the
      message is lost.
      c4ba141e
  4. 01 Nov, 2013 1 commit
    • Dries Kimpe's avatar
      Fix BMI memcache issues · 6d96c9ba
      Dries Kimpe authored
      Patch from Jingwang Zhang.
      
      Here is our use case, and we are using the BMI code in OrangeFS 2.8.6:
      
      1.       Malloc a buffer and write something to it.
      
      2.       Send the buffer using BMI routines.
      
      3.       Free the buffer and goto step 1
      
      And here we found the following problem: We found that the messages
      captured using ibdump is corrupt in iteration 2. It became a mixture of
      data from iteration 1 and iteration 2.
      
      Here is some analysis we did: We noticed that when the data corruption
      occurs, the buffer always point to the same virtual address. And after
      checking with the BMI code, we found that the memcache code will keep
      the buffer registered(to ibverbs) and use virtual address to determine
      whether a registered buffer could be reused or not later.
      
      However I think the memcache shouldn't keep the buffer registered,
      because that the user might free this buffer, and when the user did free
      and re-allocate the buffer, there might be a false match which might
      lead to data corruption.
      
      So at first, we tested the code with "define ENABLE_MEMCACHE 0" to
      disable the memcache. And then the test passed, so it is proven that the
      data corruption is caused by memcache. However, performance will be
      affected if the memcache is disabled completely.
      
      Finally we formatted the attached patch to solve the problem. It fixes
      the broken code in the clauses when memcache is disabled. And it
      deregister the buffer whenever its use-count drops to 0 and register it
      when it is used again.
      6d96c9ba
  5. 08 Oct, 2013 1 commit
  6. 06 Oct, 2013 2 commits
  7. 23 Dec, 2011 1 commit
  8. 24 Jan, 2011 1 commit
  9. 19 Jan, 2011 2 commits