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>