From: Sasha Levin Date: Sun, 11 Jul 2021 15:49:57 +0000 (-0400) Subject: Drop btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch X-Git-Tag: v5.4.132~19 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=3e00c893e0c9cb24081dcab39627cafabeba900a;p=thirdparty%2Fkernel%2Fstable-queue.git Drop btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch Signed-off-by: Sasha Levin --- diff --git a/queue-4.19/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch b/queue-4.19/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch deleted file mode 100644 index fbf879d08ee..00000000000 --- a/queue-4.19/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch +++ /dev/null @@ -1,104 +0,0 @@ -From dc680db8555a55fc2c6a357d10caaf015e233dc8 Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Mon, 31 May 2021 16:50:54 +0800 -Subject: btrfs: fix the filemap_range_has_page() call in - btrfs_punch_hole_lock_range() - -From: Qu Wenruo - -[ Upstream commit 0528476b6ac7832f31e2ed740a57ae31316b124e ] - -[BUG] -With current subpage RW support, the following script can hang the fs -with 64K page size. - - # mkfs.btrfs -f -s 4k $dev - # mount $dev -o nospace_cache $mnt - # fsstress -w -n 50 -p 1 -s 1607749395 -d $mnt - -The kernel will do an infinite loop in btrfs_punch_hole_lock_range(). - -[CAUSE] -In btrfs_punch_hole_lock_range() we: - -- Truncate page cache range -- Lock extent io tree -- Wait any ordered extents in the range. - -We exit the loop until we meet all the following conditions: - -- No ordered extent in the lock range -- No page is in the lock range - -The latter condition has a pitfall, it only works for sector size == -PAGE_SIZE case. - -While can't handle the following subpage case: - - 0 32K 64K 96K 128K - | |///////||//////| || - -lockstart=32K -lockend=96K - 1 - -In this case, although the range crosses 2 pages, -truncate_pagecache_range() will invalidate no page at all, but only zero -the [32K, 96K) range of the two pages. - -Thus filemap_range_has_page(32K, 96K-1) will always return true, thus we -will never meet the loop exit condition. - -[FIX] -Fix the problem by doing page alignment for the lock range. - -Function filemap_range_has_page() has already handled lend < lstart -case, we only need to round up @lockstart, and round_down @lockend for -truncate_pagecache_range(). - -This modification should not change any thing for sector size == -PAGE_SIZE case, as in that case our range is already page aligned. - -Tested-by: Ritesh Harjani # [ppc64] -Tested-by: Anand Jain # [aarch64] -Signed-off-by: Qu Wenruo -Reviewed-by: David Sterba -Signed-off-by: David Sterba -Signed-off-by: Sasha Levin ---- - fs/btrfs/file.c | 13 ++++++++++++- - 1 file changed, 12 insertions(+), 1 deletion(-) - -diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c -index 41ad37f8062a..cfbe2961bd1d 100644 ---- a/fs/btrfs/file.c -+++ b/fs/btrfs/file.c -@@ -2444,6 +2444,17 @@ static int btrfs_punch_hole_lock_range(struct inode *inode, - const u64 lockend, - struct extent_state **cached_state) - { -+ /* -+ * For subpage case, if the range is not at page boundary, we could -+ * have pages at the leading/tailing part of the range. -+ * This could lead to dead loop since filemap_range_has_page() -+ * will always return true. -+ * So here we need to do extra page alignment for -+ * filemap_range_has_page(). -+ */ -+ const u64 page_lockstart = round_up(lockstart, PAGE_SIZE); -+ const u64 page_lockend = round_down(lockend + 1, PAGE_SIZE) - 1; -+ - while (1) { - struct btrfs_ordered_extent *ordered; - int ret; -@@ -2463,7 +2474,7 @@ static int btrfs_punch_hole_lock_range(struct inode *inode, - (ordered->file_offset + ordered->len <= lockstart || - ordered->file_offset > lockend)) && - !filemap_range_has_page(inode->i_mapping, -- lockstart, lockend)) { -+ page_lockstart, page_lockend)) { - if (ordered) - btrfs_put_ordered_extent(ordered); - break; --- -2.30.2 - diff --git a/queue-4.19/series b/queue-4.19/series index ad2c4d22173..3204d97ed9c 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -71,7 +71,6 @@ media-siano-fix-device-register-error-path.patch media-imx-csi-skip-first-few-frames-from-a-bt.656-so.patch btrfs-fix-error-handling-in-__btrfs_update_delayed_i.patch btrfs-abort-transaction-if-we-fail-to-update-the-del.patch -btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch btrfs-disable-build-on-platforms-having-page-size-25.patch regulator-da9052-ensure-enough-delay-time-for-.set_v.patch hid-do-not-use-down_interruptible-when-unbinding-dev.patch diff --git a/queue-5.10/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch b/queue-5.10/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch deleted file mode 100644 index 67bfc84202d..00000000000 --- a/queue-5.10/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch +++ /dev/null @@ -1,104 +0,0 @@ -From 1c44f53f6296370c39909233738392fdb0f69cbc Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Mon, 31 May 2021 16:50:54 +0800 -Subject: btrfs: fix the filemap_range_has_page() call in - btrfs_punch_hole_lock_range() - -From: Qu Wenruo - -[ Upstream commit 0528476b6ac7832f31e2ed740a57ae31316b124e ] - -[BUG] -With current subpage RW support, the following script can hang the fs -with 64K page size. - - # mkfs.btrfs -f -s 4k $dev - # mount $dev -o nospace_cache $mnt - # fsstress -w -n 50 -p 1 -s 1607749395 -d $mnt - -The kernel will do an infinite loop in btrfs_punch_hole_lock_range(). - -[CAUSE] -In btrfs_punch_hole_lock_range() we: - -- Truncate page cache range -- Lock extent io tree -- Wait any ordered extents in the range. - -We exit the loop until we meet all the following conditions: - -- No ordered extent in the lock range -- No page is in the lock range - -The latter condition has a pitfall, it only works for sector size == -PAGE_SIZE case. - -While can't handle the following subpage case: - - 0 32K 64K 96K 128K - | |///////||//////| || - -lockstart=32K -lockend=96K - 1 - -In this case, although the range crosses 2 pages, -truncate_pagecache_range() will invalidate no page at all, but only zero -the [32K, 96K) range of the two pages. - -Thus filemap_range_has_page(32K, 96K-1) will always return true, thus we -will never meet the loop exit condition. - -[FIX] -Fix the problem by doing page alignment for the lock range. - -Function filemap_range_has_page() has already handled lend < lstart -case, we only need to round up @lockstart, and round_down @lockend for -truncate_pagecache_range(). - -This modification should not change any thing for sector size == -PAGE_SIZE case, as in that case our range is already page aligned. - -Tested-by: Ritesh Harjani # [ppc64] -Tested-by: Anand Jain # [aarch64] -Signed-off-by: Qu Wenruo -Reviewed-by: David Sterba -Signed-off-by: David Sterba -Signed-off-by: Sasha Levin ---- - fs/btrfs/file.c | 13 ++++++++++++- - 1 file changed, 12 insertions(+), 1 deletion(-) - -diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c -index ffa48ac98d1e..fdff99afb0be 100644 ---- a/fs/btrfs/file.c -+++ b/fs/btrfs/file.c -@@ -2485,6 +2485,17 @@ static int btrfs_punch_hole_lock_range(struct inode *inode, - const u64 lockend, - struct extent_state **cached_state) - { -+ /* -+ * For subpage case, if the range is not at page boundary, we could -+ * have pages at the leading/tailing part of the range. -+ * This could lead to dead loop since filemap_range_has_page() -+ * will always return true. -+ * So here we need to do extra page alignment for -+ * filemap_range_has_page(). -+ */ -+ const u64 page_lockstart = round_up(lockstart, PAGE_SIZE); -+ const u64 page_lockend = round_down(lockend + 1, PAGE_SIZE) - 1; -+ - while (1) { - struct btrfs_ordered_extent *ordered; - int ret; -@@ -2505,7 +2516,7 @@ static int btrfs_punch_hole_lock_range(struct inode *inode, - (ordered->file_offset + ordered->num_bytes <= lockstart || - ordered->file_offset > lockend)) && - !filemap_range_has_page(inode->i_mapping, -- lockstart, lockend)) { -+ page_lockstart, page_lockend)) { - if (ordered) - btrfs_put_ordered_extent(ordered); - break; --- -2.30.2 - diff --git a/queue-5.10/series b/queue-5.10/series index 8351e55c812..ad8264ca60f 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -156,7 +156,6 @@ kvm-ppc-book3s-hv-fix-tlb-management-on-smt8-power9-.patch btrfs-fix-error-handling-in-__btrfs_update_delayed_i.patch btrfs-abort-transaction-if-we-fail-to-update-the-del.patch btrfs-sysfs-fix-format-string-for-some-discard-stats.patch -btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch btrfs-don-t-clear-page-extent-mapped-if-we-re-not-in.patch btrfs-disable-build-on-platforms-having-page-size-25.patch locking-lockdep-fix-the-dep-path-printing-for-backwa.patch diff --git a/queue-5.12/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch b/queue-5.12/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch deleted file mode 100644 index 270a6041436..00000000000 --- a/queue-5.12/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch +++ /dev/null @@ -1,104 +0,0 @@ -From 57c6d5d75a485267c00abc94b0f5f7f0333b87b8 Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Mon, 31 May 2021 16:50:54 +0800 -Subject: btrfs: fix the filemap_range_has_page() call in - btrfs_punch_hole_lock_range() - -From: Qu Wenruo - -[ Upstream commit 0528476b6ac7832f31e2ed740a57ae31316b124e ] - -[BUG] -With current subpage RW support, the following script can hang the fs -with 64K page size. - - # mkfs.btrfs -f -s 4k $dev - # mount $dev -o nospace_cache $mnt - # fsstress -w -n 50 -p 1 -s 1607749395 -d $mnt - -The kernel will do an infinite loop in btrfs_punch_hole_lock_range(). - -[CAUSE] -In btrfs_punch_hole_lock_range() we: - -- Truncate page cache range -- Lock extent io tree -- Wait any ordered extents in the range. - -We exit the loop until we meet all the following conditions: - -- No ordered extent in the lock range -- No page is in the lock range - -The latter condition has a pitfall, it only works for sector size == -PAGE_SIZE case. - -While can't handle the following subpage case: - - 0 32K 64K 96K 128K - | |///////||//////| || - -lockstart=32K -lockend=96K - 1 - -In this case, although the range crosses 2 pages, -truncate_pagecache_range() will invalidate no page at all, but only zero -the [32K, 96K) range of the two pages. - -Thus filemap_range_has_page(32K, 96K-1) will always return true, thus we -will never meet the loop exit condition. - -[FIX] -Fix the problem by doing page alignment for the lock range. - -Function filemap_range_has_page() has already handled lend < lstart -case, we only need to round up @lockstart, and round_down @lockend for -truncate_pagecache_range(). - -This modification should not change any thing for sector size == -PAGE_SIZE case, as in that case our range is already page aligned. - -Tested-by: Ritesh Harjani # [ppc64] -Tested-by: Anand Jain # [aarch64] -Signed-off-by: Qu Wenruo -Reviewed-by: David Sterba -Signed-off-by: David Sterba -Signed-off-by: Sasha Levin ---- - fs/btrfs/file.c | 13 ++++++++++++- - 1 file changed, 12 insertions(+), 1 deletion(-) - -diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c -index f21d98c73878..9c00cabcf0da 100644 ---- a/fs/btrfs/file.c -+++ b/fs/btrfs/file.c -@@ -2483,6 +2483,17 @@ static int btrfs_punch_hole_lock_range(struct inode *inode, - const u64 lockend, - struct extent_state **cached_state) - { -+ /* -+ * For subpage case, if the range is not at page boundary, we could -+ * have pages at the leading/tailing part of the range. -+ * This could lead to dead loop since filemap_range_has_page() -+ * will always return true. -+ * So here we need to do extra page alignment for -+ * filemap_range_has_page(). -+ */ -+ const u64 page_lockstart = round_up(lockstart, PAGE_SIZE); -+ const u64 page_lockend = round_down(lockend + 1, PAGE_SIZE) - 1; -+ - while (1) { - struct btrfs_ordered_extent *ordered; - int ret; -@@ -2503,7 +2514,7 @@ static int btrfs_punch_hole_lock_range(struct inode *inode, - (ordered->file_offset + ordered->num_bytes <= lockstart || - ordered->file_offset > lockend)) && - !filemap_range_has_page(inode->i_mapping, -- lockstart, lockend)) { -+ page_lockstart, page_lockend)) { - if (ordered) - btrfs_put_ordered_extent(ordered); - break; --- -2.30.2 - diff --git a/queue-5.12/series b/queue-5.12/series index 9fbcb865e1b..59bd8bcf67b 100644 --- a/queue-5.12/series +++ b/queue-5.12/series @@ -184,7 +184,6 @@ btrfs-fix-error-handling-in-__btrfs_update_delayed_i.patch btrfs-abort-transaction-if-we-fail-to-update-the-del.patch btrfs-always-abort-the-transaction-if-we-abort-a-tra.patch btrfs-sysfs-fix-format-string-for-some-discard-stats.patch -btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch btrfs-don-t-clear-page-extent-mapped-if-we-re-not-in.patch btrfs-disable-build-on-platforms-having-page-size-25.patch locking-lockdep-fix-the-dep-path-printing-for-backwa.patch diff --git a/queue-5.13/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch b/queue-5.13/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch deleted file mode 100644 index e2741a12201..00000000000 --- a/queue-5.13/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch +++ /dev/null @@ -1,104 +0,0 @@ -From c8e07d10d221aa84cdc6a8524617d83ff364881c Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Mon, 31 May 2021 16:50:54 +0800 -Subject: btrfs: fix the filemap_range_has_page() call in - btrfs_punch_hole_lock_range() - -From: Qu Wenruo - -[ Upstream commit 0528476b6ac7832f31e2ed740a57ae31316b124e ] - -[BUG] -With current subpage RW support, the following script can hang the fs -with 64K page size. - - # mkfs.btrfs -f -s 4k $dev - # mount $dev -o nospace_cache $mnt - # fsstress -w -n 50 -p 1 -s 1607749395 -d $mnt - -The kernel will do an infinite loop in btrfs_punch_hole_lock_range(). - -[CAUSE] -In btrfs_punch_hole_lock_range() we: - -- Truncate page cache range -- Lock extent io tree -- Wait any ordered extents in the range. - -We exit the loop until we meet all the following conditions: - -- No ordered extent in the lock range -- No page is in the lock range - -The latter condition has a pitfall, it only works for sector size == -PAGE_SIZE case. - -While can't handle the following subpage case: - - 0 32K 64K 96K 128K - | |///////||//////| || - -lockstart=32K -lockend=96K - 1 - -In this case, although the range crosses 2 pages, -truncate_pagecache_range() will invalidate no page at all, but only zero -the [32K, 96K) range of the two pages. - -Thus filemap_range_has_page(32K, 96K-1) will always return true, thus we -will never meet the loop exit condition. - -[FIX] -Fix the problem by doing page alignment for the lock range. - -Function filemap_range_has_page() has already handled lend < lstart -case, we only need to round up @lockstart, and round_down @lockend for -truncate_pagecache_range(). - -This modification should not change any thing for sector size == -PAGE_SIZE case, as in that case our range is already page aligned. - -Tested-by: Ritesh Harjani # [ppc64] -Tested-by: Anand Jain # [aarch64] -Signed-off-by: Qu Wenruo -Reviewed-by: David Sterba -Signed-off-by: David Sterba -Signed-off-by: Sasha Levin ---- - fs/btrfs/file.c | 13 ++++++++++++- - 1 file changed, 12 insertions(+), 1 deletion(-) - -diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c -index 55f68422061d..7e6ed97a6d08 100644 ---- a/fs/btrfs/file.c -+++ b/fs/btrfs/file.c -@@ -2483,6 +2483,17 @@ static int btrfs_punch_hole_lock_range(struct inode *inode, - const u64 lockend, - struct extent_state **cached_state) - { -+ /* -+ * For subpage case, if the range is not at page boundary, we could -+ * have pages at the leading/tailing part of the range. -+ * This could lead to dead loop since filemap_range_has_page() -+ * will always return true. -+ * So here we need to do extra page alignment for -+ * filemap_range_has_page(). -+ */ -+ const u64 page_lockstart = round_up(lockstart, PAGE_SIZE); -+ const u64 page_lockend = round_down(lockend + 1, PAGE_SIZE) - 1; -+ - while (1) { - struct btrfs_ordered_extent *ordered; - int ret; -@@ -2503,7 +2514,7 @@ static int btrfs_punch_hole_lock_range(struct inode *inode, - (ordered->file_offset + ordered->num_bytes <= lockstart || - ordered->file_offset > lockend)) && - !filemap_range_has_page(inode->i_mapping, -- lockstart, lockend)) { -+ page_lockstart, page_lockend)) { - if (ordered) - btrfs_put_ordered_extent(ordered); - break; --- -2.30.2 - diff --git a/queue-5.13/series b/queue-5.13/series index a4bc4b4fa66..2e4662ab224 100644 --- a/queue-5.13/series +++ b/queue-5.13/series @@ -196,7 +196,6 @@ btrfs-fix-error-handling-in-__btrfs_update_delayed_i.patch btrfs-abort-transaction-if-we-fail-to-update-the-del.patch btrfs-always-abort-the-transaction-if-we-abort-a-tra.patch btrfs-sysfs-fix-format-string-for-some-discard-stats.patch -btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch btrfs-don-t-clear-page-extent-mapped-if-we-re-not-in.patch btrfs-disable-build-on-platforms-having-page-size-25.patch locking-lockdep-fix-the-dep-path-printing-for-backwa.patch diff --git a/queue-5.4/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch b/queue-5.4/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch deleted file mode 100644 index 06e1ea2a09e..00000000000 --- a/queue-5.4/btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch +++ /dev/null @@ -1,104 +0,0 @@ -From 10014a1ddf64b0dd5ec940b59fa8981c7f8c5e22 Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Mon, 31 May 2021 16:50:54 +0800 -Subject: btrfs: fix the filemap_range_has_page() call in - btrfs_punch_hole_lock_range() - -From: Qu Wenruo - -[ Upstream commit 0528476b6ac7832f31e2ed740a57ae31316b124e ] - -[BUG] -With current subpage RW support, the following script can hang the fs -with 64K page size. - - # mkfs.btrfs -f -s 4k $dev - # mount $dev -o nospace_cache $mnt - # fsstress -w -n 50 -p 1 -s 1607749395 -d $mnt - -The kernel will do an infinite loop in btrfs_punch_hole_lock_range(). - -[CAUSE] -In btrfs_punch_hole_lock_range() we: - -- Truncate page cache range -- Lock extent io tree -- Wait any ordered extents in the range. - -We exit the loop until we meet all the following conditions: - -- No ordered extent in the lock range -- No page is in the lock range - -The latter condition has a pitfall, it only works for sector size == -PAGE_SIZE case. - -While can't handle the following subpage case: - - 0 32K 64K 96K 128K - | |///////||//////| || - -lockstart=32K -lockend=96K - 1 - -In this case, although the range crosses 2 pages, -truncate_pagecache_range() will invalidate no page at all, but only zero -the [32K, 96K) range of the two pages. - -Thus filemap_range_has_page(32K, 96K-1) will always return true, thus we -will never meet the loop exit condition. - -[FIX] -Fix the problem by doing page alignment for the lock range. - -Function filemap_range_has_page() has already handled lend < lstart -case, we only need to round up @lockstart, and round_down @lockend for -truncate_pagecache_range(). - -This modification should not change any thing for sector size == -PAGE_SIZE case, as in that case our range is already page aligned. - -Tested-by: Ritesh Harjani # [ppc64] -Tested-by: Anand Jain # [aarch64] -Signed-off-by: Qu Wenruo -Reviewed-by: David Sterba -Signed-off-by: David Sterba -Signed-off-by: Sasha Levin ---- - fs/btrfs/file.c | 13 ++++++++++++- - 1 file changed, 12 insertions(+), 1 deletion(-) - -diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c -index f6308a7b761d..b678bf7692d5 100644 ---- a/fs/btrfs/file.c -+++ b/fs/btrfs/file.c -@@ -2439,6 +2439,17 @@ static int btrfs_punch_hole_lock_range(struct inode *inode, - const u64 lockend, - struct extent_state **cached_state) - { -+ /* -+ * For subpage case, if the range is not at page boundary, we could -+ * have pages at the leading/tailing part of the range. -+ * This could lead to dead loop since filemap_range_has_page() -+ * will always return true. -+ * So here we need to do extra page alignment for -+ * filemap_range_has_page(). -+ */ -+ const u64 page_lockstart = round_up(lockstart, PAGE_SIZE); -+ const u64 page_lockend = round_down(lockend + 1, PAGE_SIZE) - 1; -+ - while (1) { - struct btrfs_ordered_extent *ordered; - int ret; -@@ -2458,7 +2469,7 @@ static int btrfs_punch_hole_lock_range(struct inode *inode, - (ordered->file_offset + ordered->len <= lockstart || - ordered->file_offset > lockend)) && - !filemap_range_has_page(inode->i_mapping, -- lockstart, lockend)) { -+ page_lockstart, page_lockend)) { - if (ordered) - btrfs_put_ordered_extent(ordered); - break; --- -2.30.2 - diff --git a/queue-5.4/series b/queue-5.4/series index cf297274a2b..518396b161c 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -102,7 +102,6 @@ drivers-perf-fix-the-missed-ida_simple_remove-in-ddr.patch kvm-ppc-book3s-hv-fix-tlb-management-on-smt8-power9-.patch btrfs-fix-error-handling-in-__btrfs_update_delayed_i.patch btrfs-abort-transaction-if-we-fail-to-update-the-del.patch -btrfs-fix-the-filemap_range_has_page-call-in-btrfs_p.patch btrfs-disable-build-on-platforms-having-page-size-25.patch locking-lockdep-fix-the-dep-path-printing-for-backwa.patch lockding-lockdep-avoid-to-find-wrong-lock-dep-path-i.patch