Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-16412

check truncated page in ->read page()

    XMLWordPrintable

Details

    • 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

            People

              qian_wc Qian Yingjin
              qian_wc Qian Yingjin
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: