[LU-14357] Simplify locking in fid_request Created: 22/Jan/21 Updated: 05/May/21 Resolved: 05/May/21 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.15.0 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Neil Brown | Assignee: | Neil Brown |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Rank (Obsolete): | 9223372036854775807 |
| Description |
|
The lu_client_seq contains a mutex, lcs_mutex, which is used for serialising updates to the fid, in fid_request. It also contains waitq and flag, lcs_waitq and lcs_update, which effectively provide a second mutex. This appear to add no value. The second mutex is held while and rpc to the server to get a new fid is pending. Originally there was just the one mutex, but in Commit 23e2a370c8a3 ("b=24255 move seq_client_alloc_seq out of lcs_sem") the second was added. The apparent reason was that "in a case of recovery the recovery thread takes [lcs_murex] too and deadlocks. This presumably refers to seq_client_flush as that seems to be the only relevant place which takes lcs_mutex but doesn't take the new open-coded mutex. However this was changed in Commit d1feb5c774d4 (" As this doesn't appear to have brought back the deadlock that was originally a concern, we must assume that the deadlock possibility has disappeared for other reasons. So this open-coded mutex can be removed and the code simplified.
|
| Comments |
| Comment by Gerrit Updater [ 22/Jan/21 ] |
|
Neil Brown (neilb@suse.de) uploaded a new patch: https://review.whamcloud.com/41299 |
| Comment by Gerrit Updater [ 05/May/21 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/41299/ |
| Comment by Peter Jones [ 05/May/21 ] |
|
Landed for 2.15 |