mds: flock: remove auto-insertion of waiting locks.

I don't remember precisely why I had the locking do this (maybe
just for self-containment), but with the messages being re-processed
anyway it's just redundant, and was leading to lots of erroneous
EINTR results.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>

1 files changed, 0 insertions, 27 deletions

diff --git a/src/mds/flock.cc b/src/mds/flock.cc
index c890617b160..b97aa013118 100644
--- a/src/mds/flock.cc
+++ b/src/mds/flock.cc
@@ -180,33 +180,6 @@ void ceph_lock_state_t::remove_lock(ceph_filelock removal_lock,
       client_held_lock_counts.erase(old_lock_client);
     }
   }
-
-  /* okay, we've removed the locks, but removing them might allow some
-   * other waiting locks to come through */
-  if (get_waiting_overlaps(removal_lock, crossed_waiting_locks)) {
-    /*let's do this the SUPER lazy way for now. Should work out something
-      that's slightly less slow and wasteful, though.
-      1) Remove lock from waiting_locks.
-      2) attempt to insert lock via add_lock
-      3) Add to success list if we get back "true"
-
-      In the future, should probably set this up to detect some
-      guaranteed blocks and do fewer map lookups.
-     */
-    for (list<multimap<uint64_t, ceph_filelock>::iterator>::iterator
-           iter = crossed_waiting_locks.begin();
-         iter != crossed_waiting_locks.end();
-         ++iter) {
-      ceph_filelock cur_lock = (*iter)->second;
-      waiting_locks.erase(*iter);
-      --client_waiting_lock_counts[(client_t)cur_lock.client];
-      if (!client_waiting_lock_counts[(client_t)cur_lock.client]) {
-        client_waiting_lock_counts.erase((client_t)cur_lock.client);
-      }
-      if (add_lock(cur_lock, true))
-        activated_locks.push_back(cur_lock);
-    }
-  }
 }
 
 bool ceph_lock_state_t::remove_all_from (client_t client)