[LU-12460] lli_trunc_sem can lead to a readlock Created: 20/Jun/19 Updated: 03/Dec/21 Resolved: 23/Jan/20 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.13.0, Lustre 2.12.2 |
| Fix Version/s: | Lustre 2.14.0 |
| Type: | Bug | Priority: | Major |
| Reporter: | James A Simmons | Assignee: | Neil Brown |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Any lustre client |
||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
Neil Brown discovered during the linux lustre client work a potential read lock condition involving lli_trunc_sem. If you mmap a lustre file, then read into that mapped memory from the file they can shared the same mmap_sem which does is okay since they are down_read() calls. The read lock can happen if truncate is called in between memory mapping the file and reading into the that mapped memory from the file. |
| Comments |
| Comment by Gerrit Updater [ 20/Jun/19 ] |
|
James Simmons (uja.ornl@yahoo.com) uploaded a new patch: https://review.whamcloud.com/35271 |
| Comment by Andreas Dilger [ 20/Jun/19 ] |
|
James, your bug description doesn't quite make sense. Is there supposed to be a write lock somewhere in there? I haven't looked at the CLIO code in a while, but we used to have a check for the source pages coming from mmapped memory of the target file, or vice versa. |
| Comment by James A Simmons [ 20/Jun/19 ] |
|
Yeah the details were lacking at the time I opened the ticket. It was based on what was in the patch. As the discussion continues this ticket description can be updated. |
| Comment by Patrick Farrell (Inactive) [ 20/Jun/19 ] |
|
James, I asked this in Gerrit but didn't see a response - Has this patch been on a mailing list and I missed it? Or is this the first appearance of it? If it's been on a mailing list, which one? |
| Comment by Gerrit Updater [ 20/Jun/19 ] |
|
Patrick Farrell (pfarrell@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/35283 |
| Comment by Neil Brown [ 20/Jun/19 ] |
|
Patrick, that patch has been in my lustre-testing branch for a while, but I hadn't posted it because I really want there to be a better way - so I was procrastinating. James did post it to the list on 20th May with a bunch of patches which were patches from my lustre-testing which he had modified to varying extents (I've merged the changes I liked into my lustre-testing). You might remember discussing your "ll_fault fixes" patch that was in the series and I had questions about it. It was patch 1 of the series. This patch was patch 3 (of 29). |
| Comment by Patrick Farrell (Inactive) [ 21/Jun/19 ] |
|
Right, thank you - Obviously, I did not read through the full series...... |
| Comment by Gerrit Updater [ 23/Jan/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/35271/ |
| Comment by Peter Jones [ 23/Jan/20 ] |
|
Landed for 2.14 |