[LU-14877] Lock inversion between inode mutex and layout mutex Created: 21/Jul/21  Updated: 16/Sep/21  Resolved: 31/Aug/21

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.15.0

Type: Bug Priority: Major
Reporter: Oleg Drokin Assignee: Oleg Drokin
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Related
is related to LU-812 Support for Linux 3.0 kernels Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

ll_fsync is taking an inode mutex and then creates IO that might go into layout refresh that might take layout mutex and block for IOs to finish

write path might go into vvp_io_write_start with active IOs already incremented because IO was started and block on the locked inode held by ll_fsync.

Thus the deadlock.

It looks like we don't really need the inode lock held in ll_fsync at at least not for as much? the LU-812 does not go into a lot of explanations on the reasons behind adding the locking there.



 Comments   
Comment by Gerrit Updater [ 21/Jul/21 ]

Oleg Drokin (green@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/44368
Subject: LU-14877 llite: Remove inode locking in ll_fsync
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: e5a21157d776b294fbfc3c853c0de887cf1b8223

Comment by Gerrit Updater [ 26/Jul/21 ]

Pushed patch against wrong LU - whoops!

Comment by Gerrit Updater [ 31/Aug/21 ]

"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/44368/
Subject: LU-14877 llite: Remove inode locking in ll_fsync
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: e8d76d1090e912ee5d916284ca5c8ba9195ddd9b

Comment by Peter Jones [ 31/Aug/21 ]

Landed for 2.15

Generated at Sat Feb 10 03:13:33 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.