[RFC dlm/next 0/9] dlm: sand fix, rhashtable, timers and lookup hotpath speedup

[Alexander Aring <aahringo@redhat.com>]

Hi,

this is a RFC for an immense change in DLM rsb hashtable logic. It
removes the double lookup functionality for rsb hashtables, convert to
rhashtable instead of own bucket hlist hash implementation.

At first there is a fix for scand that I detected while I was
implementing this patch series. It could be that remove messages are
still send when the lockspace is releasing the resource that could occur
into a use after free.

There is a conversion to use lists (keep/toss lists) instead of
iterating over the hash bucket. As we do a transition to rhashtable,
they don't like to being iterated regarding to their own bucket sizing
implementation that is sitting in the rhashtable implementation. We just
introduce the lists to do the iteration, as advantage we have a huge
reduce of code in the debugfs dump functionality as we use the dump list
helpers of debugfs. There is also a potential refcount bug when holding
rsb references of rsbs in toss state as receive remove message requires
no rsb references being hold. Another issue is also holding rsb in keep
state as they are not going into toss state when they required to.

It is now forbidden to hold references of rsbs in toss state. The
refcounter must be only functional in rsb keep state. That hopefully
will show is more invalid usage of the rsb refcounter if the rsb is in
toss state.

The scand was being fixed but now also it's removed. The scand process
was holding the hashtable/hash bucket lock for a longer timer because it
iterated over the whole hash. We use timers now to reduce the held time
of the hashtable lock. We take here the advantage of the timers
data structure that the rsb timer will delete the rsb itself from the
hash. No lookup required as this is part of the timer subsystem.

As end we move very likely lookup hotpath to read lock mostly. This
should for sure avoid contention in the most cases. Unlikely path need
to still hold the write lock and do some extra relookup and check if the
state of an rsb changed. However I think we hit over 90% the likely path
that we only need to hold the read lock and avoid contention between
processing DLM messages and the user triggers new DLM requests.

- Alex

Alexander Aring (9):
  dlm: increment ls_count on find_ls_to_scan()
  dlm: change to non per bucket hashtable lock
  dlm: merge toss and keep hash into one
  dlm: fix avoid rsb hold during debugfs dump
  dlm: switch to use rhashtable for rsbs
  dlm: remove refcounting if rsb is on toss
  dlm: drop scand kthread and use timers
  dlm: likely read lock path for rsb lookup
  dlm: convert lkbidr to rwlock

 fs/dlm/config.c       |   8 +
 fs/dlm/config.h       |   2 +
 fs/dlm/debug_fs.c     | 212 ++----------
 fs/dlm/dir.c          |  14 +-
 fs/dlm/dlm_internal.h |  39 +--
 fs/dlm/lock.c         | 774 ++++++++++++++++++++++--------------------
 fs/dlm/lock.h         |   3 +-
 fs/dlm/lockspace.c    | 151 ++------
 fs/dlm/recover.c      |  38 ++-
 fs/dlm/recoverd.c     |  40 +--
 10 files changed, 541 insertions(+), 740 deletions(-)

-- 
2.43.0