Whamcloud - gitweb
LU-14357 fid: simplify locking for fid updates 99/41299/2
authorMr NeilBrown <neilb@suse.de>
Fri, 22 Jan 2021 02:42:33 +0000 (13:42 +1100)
committerOleg Drokin <green@whamcloud.com>
Wed, 5 May 2021 02:49:56 +0000 (02:49 +0000)
commitaba940fa10195579eac0701846922547c6ad0dae
tree6dc4ea8e792d1f85edf88e37f65c407c1b826033
parent71b2476e4ddb95aa42f4a0ea3f23b1826017bfa5
LU-14357 fid: simplify locking for fid updates

'struct lu_client_seq' contains a mutex (lcs_mutex) and a second
open-coded mutex (lcs_waitq, lcs_update).  Both of these are using in
gettign a new fid, possibly from the server.

lcs_mutex is the main mutex which protects the local variables.  If an
RPC to the server is required, the extra mutex is held during that
RPC.

This was apparently intended to avoid some deadlock, presumably with
seq_client_flush().  However as seq_client_flush() now takes both
mutexes as well, it is still prone to any such deadlock, but does not
appear to actually suffer from one.
See:
  Commit 23e2a370c8a3 ("b=24255 move seq_client_alloc_seq out of
   lcs_sem")
  Commit d1feb5c774d4 ("LU-662 fix conflict between seq_client_flush
   and seq_client_alloc_fid")

for some of the history.

The extra open-coded mutex appears to provide no value, so let's
remove it.

As part of this, seq_fid_alloc_fini() is open-coded into the two call
sites, which adds further simplification.

Signed-off-by: Mr NeilBrown <neilb@suse.de>
Change-Id: Ia39eca7d925c9d49fbf942923de8af79dba4f6bf
Reviewed-on: https://review.whamcloud.com/41299
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: James Simmons <jsimmons@infradead.org>
Reviewed-by: Alex Zhuravlev <bzzz@whamcloud.com>
Reviewed-by: Lai Siyao <lai.siyao@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
lustre/fid/fid_request.c
lustre/include/lustre_fid.h