Details
-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
None
-
3
-
9223372036854775807
Description
I found the page end offset calculation in filemap_get_read_batch() was off by one in 5.x kernel.
When a read is submitted with end offset 1048575, then it incorrectly calculates
the end page for read of 1024 when it should be 1023. This result in the readpage() call of the page is over stripe boundary and may be not covered by a DLM extent lock.
In some corner racer case, filemap_get_read_batch() batches the page with index 1024 for read, but later this page is truncated and removed from page cache due to the lock protected it being revoked. This results in this page in the read path is not covered by a DLM lock. This will trigger an assertion in the code:
LustreError: 14129:0:(osc_object.c:397:osc_req_attr_set()) uncovered page! Pid: 14129, comm: ptlrpcd_04_18 5.14.0-1038-oem #42-Ubuntu SMP Thu May 19 05:03:08 UTC 2022 LustreError: 14129:0:(osc_object.c:411:osc_req_attr_set()) LBUG
To work around this bug in the kernel, we can simply check whether this page got truncated and was removed from page cache in ->readpage(), and return AOP_TRUNCATED_PAGE to the upper layer, and then it will retry to batch pages and it will not add this truncated page into batches as it was removed from page cache.
Attachments
Issue Links
Activity
| Link | New: This issue is related to DDN-5149 [ DDN-5149 ] |
| Link | New: This issue is related to DDN-3986 [ DDN-3986 ] |
| Labels | Original: LTS15 |
| Link | New: This issue is related to NCP-12 [ NCP-12 ] |
| Fix Version/s | New: Lustre 2.15.3 [ 15998 ] |
| Link | New: This issue is blocked by EX-6850 [ EX-6850 ] |
| Labels | New: LTS15 |
| Description |
Original:
I found the page end offset calculation in filemap_get_read_batch() was off by one in 5.x kernel.
When a read is submitted with end offset 1048575, then it calculates the end page for read of 1024 when it should be 1023. This result in the readpage() call of the page is over stripe boundary and may be not covered by a DLM extent lock. In some corner racer case, filemap_get_read_batch() batches the page with index 1024 for read, but later this page is truncated and removed from page cache due to the lock protected it being revoked. This results in this page in the read path is not covered by a DLM lock. We can simply check whether this page got truncated and was removed from page cache in ->readpage(), and return AOP_TRUNCATED_PAGE to the upper layer, and then it will retry to batch pages and it will not add this truncated page into batches as it was removed from page cache. |
New:
I found the page end offset calculation in filemap_get_read_batch() was off by one in 5.x kernel.
When a read is submitted with end offset 1048575, then it incorrectly calculates the end page for read of 1024 when it should be 1023. This result in the {{readpage()}} call of the page is over stripe boundary and may be not covered by a DLM extent lock. In some corner racer case, {{filemap_get_read_batch()}} batches the page with index 1024 for read, but later this page is truncated and removed from page cache due to the lock protected it being revoked. This results in this page in the read path is not covered by a DLM lock. This will trigger an assertion in the code: {noformat} LustreError: 14129:0:(osc_object.c:397:osc_req_attr_set()) uncovered page! Pid: 14129, comm: ptlrpcd_04_18 5.14.0-1038-oem #42-Ubuntu SMP Thu May 19 05:03:08 UTC 2022 LustreError: 14129:0:(osc_object.c:411:osc_req_attr_set()) LBUG {noformat} To work around this bug in the kernel, we can simply check whether this page got truncated and was removed from page cache in {{->readpage()}}, and return {{AOP_TRUNCATED_PAGE}} to the upper layer, and then it will retry to batch pages and it will not add this truncated page into batches as it was removed from page cache. |