The condition checking for THP straddling end of invalidated range is
wrong - it checks 'index' against 'end' but 'index' has been already
advanced to point to the end of THP and thus the condition can never be
true. As a result THP straddling 'end' has been fully invalidated. Given
the nature of invalidate_mapping_pages(), this could be only performance
issue. In fact, we are lucky the condition is wrong because if it was
ever true, we'd leave locked page behind.

Fix the condition checking for THP straddling 'end' and also properly
unlock the page. Also update the comment before the condition to explain
why we decide not to invalidate the page as it was not clear to me and I
had to ask Kirill.

Signed-off-by: Jan Kara <j...@suse.cz>
---
 mm/truncate.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/mm/truncate.c b/mm/truncate.c
index 6479ed2afc53..2330223841fb 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -530,9 +530,15 @@ unsigned long invalidate_mapping_pages(struct 
address_space *mapping,
                        } else if (PageTransHuge(page)) {
                                index += HPAGE_PMD_NR - 1;
                                i += HPAGE_PMD_NR - 1;
-                               /* 'end' is in the middle of THP */
-                               if (index ==  round_down(end, HPAGE_PMD_NR))
+                               /*
+                                * 'end' is in the middle of THP. Don't
+                                * invalidate the page as the part outside of
+                                * 'end' could be still useful.
+                                */
+                               if (index > end) {
+                                       unlock_page(page);
                                        continue;
+                               }
                        }
 
                        ret = invalidate_inode_page(page);
-- 
2.12.3

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to