[LU-3273] mdt_mfd_open() may call mdt_handle2mfd() w/o holding med_open_lock Created: 04/May/13 Updated: 19/Dec/13 Resolved: 19/Dec/13 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.4.0 |
| Fix Version/s: | Lustre 2.5.0, Lustre 2.4.2 |
| Type: | Bug | Priority: | Minor |
| Reporter: | John Hammond | Assignee: | John Hammond |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | mdt, patch | ||
| Severity: | 3 |
| Rank (Obsolete): | 8110 |
| 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 |
| Comment by Alex Zhuravlev [ 04/May/13 ] |
|
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. |
| Comment by Andreas Dilger [ 06/May/13 ] |
|
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. |
| Comment by Swapnil Pimpale (Inactive) [ 08/Aug/13 ] |
|
I have submitted a patch to fix this bug here (http://review.whamcloud.com/#/c/7272/) |
| Comment by John Hammond [ 17/Sep/13 ] |
|
Patch landed to master. |