[LU-3273] mdt_mfd_open() may call mdt_handle2mfd() w/o holding med_open_lock

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.5.0, Lustre 2.4.2
• Affects Version/s: Lustre 2.4.0
• Labels: mdt patch
• Severity: 3
• Assignee: John Hammond
• Reporter: John Hammond

Description

During replay mdt_mfd_open() calls mdt_handle2mfd() with out holding the med_open_lock. This seems like an potentially unsafe walk of the med_open_head list. It later takes the lock to unlink mfd, but it does not seem to check that it has won the possible race to unlink this mfd.

Comments

[John Hammond]

Patch landed to master.

[Swapnil Pimpale (Inactive)]

I have submitted a patch to fix this bug here (http://review.whamcloud.com/#/c/7272/)

[Andreas Dilger]

Alex, is it true that recovery is still single-threaded today? I thought I saw issues in the past where this assumption was incorrect? In any case, holding locks in the single-threaded case would not cause contention, and makes the code more correct for readers and for static code analysis tools.

[Alex Zhuravlev]

during replay we do not have any concurrency at the moment. literally all the replays are done within the context of special recovery thread, one by one.