[LU-13940] it_lock_bits should be bit-wise tested Created: 02/Sep/20 Updated: 19/Sep/20 Resolved: 19/Sep/20 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.14.0 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Shaun Tancheff | Assignee: | Shaun Tancheff |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Severity: | 3 |
| Rank (Obsolete): | 9223372036854775807 |
| Description |
|
It was noted during a code review that struct lookup_intent member it_lock_bits is a bitfield but there was a location where it was being tested by an equality test ( != MDS_INODELOCK_OPEN) If lock_mode is not set then ensure that it_lock_bits has the MDS_INODELOCK_OPEN bit set |
| Comments |
| Comment by Gerrit Updater [ 02/Sep/20 ] |
|
Shaun Tancheff (shaun.tancheff@hpe.com) uploaded a new patch: https://review.whamcloud.com/39797 |
| Comment by Andreas Dilger [ 03/Sep/20 ] |
|
Can you please update the ticket with more information about how/when/why this problem is hit, rather than just the patch summary that describes what the patch does. Otherwise, it is very difficult to make any assessment of how often "whatever this problem is" is hit, and what the consequences of hitting it are. Is it easily hit with a specific workload, does it cause a crash, does it cause data inconsistency or loss, or only an occasional problem that is seen under a specific workload, or just a build problem on a certain kernel or GCC? |
| Comment by Shaun Tancheff [ 03/Sep/20 ] |
|
This was noted during a code review. I do not have a test that causes this condition to fault. |
| Comment by Andreas Dilger [ 03/Sep/20 ] |
|
Thanks for the update. This makes it easier to understand the impact of the bug and eg. whether it is important to backport to 2.12 or not. |
| Comment by Gerrit Updater [ 19/Sep/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/39797/ |
| Comment by Peter Jones [ 19/Sep/20 ] |
|
Landed for 2.14 |