5.10-stable patches

added patches:
	btrfs-limit-device-extents-to-the-device-size.patch
	btrfs-zlib-zero-initialize-zlib-workspace.patch

diff --git a/queue-5.10/btrfs-limit-device-extents-to-the-device-size.patch b/queue-5.10/btrfs-limit-device-extents-to-the-device-size.patch
new file mode 100644 (file)
index 0000000..1e325a1
--- /dev/null
+++ b/queue-5.10/btrfs-limit-device-extents-to-the-device-size.patch
@@ -0,0 +1,66 @@
+From 3c538de0f2a74d50aff7278c092f88ae59cee688 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Wed, 18 Jan 2023 16:35:13 -0500
+Subject: btrfs: limit device extents to the device size
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit 3c538de0f2a74d50aff7278c092f88ae59cee688 upstream.
+
+There was a recent regression in btrfs/177 that started happening with
+the size class patches ("btrfs: introduce size class to block group
+allocator").  This however isn't a regression introduced by those
+patches, but rather the bug was uncovered by a change in behavior in
+these patches.  The patches triggered more chunk allocations in the
+^free-space-tree case, which uncovered a race with device shrink.
+
+The problem is we will set the device total size to the new size, and
+use this to find a hole for a device extent.  However during shrink we
+may have device extents allocated past this range, so we could
+potentially find a hole in a range past our new shrink size.  We don't
+actually limit our found extent to the device size anywhere, we assume
+that we will not find a hole past our device size.  This isn't true with
+shrink as we're relocating block groups and thus creating holes past the
+device size.
+
+Fix this by making sure we do not search past the new device size, and
+if we wander into any device extents that start after our device size
+simply break from the loop and use whatever hole we've already found.
+
+CC: stable@vger.kernel.org # 4.14+
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/volumes.c |    6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -1580,7 +1580,7 @@ again:
+                       goto out;
+       }
+ 
+-      while (1) {
++      while (search_start < search_end) {
+               l = path->nodes[0];
+               slot = path->slots[0];
+               if (slot >= btrfs_header_nritems(l)) {
+@@ -1603,6 +1603,9 @@ again:
+               if (key.type != BTRFS_DEV_EXTENT_KEY)
+                       goto next;
+ 
++              if (key.offset > search_end)
++                      break;
++
+               if (key.offset > search_start) {
+                       hole_size = key.offset - search_start;
+                       dev_extent_hole_check(device, &search_start, &hole_size,
+@@ -1663,6 +1666,7 @@ next:
+       else
+               ret = 0;
+ 
++      ASSERT(max_hole_start + max_hole_size <= search_end);
+ out:
+       btrfs_free_path(path);
+       *start = max_hole_start;

diff --git a/queue-5.10/btrfs-zlib-zero-initialize-zlib-workspace.patch b/queue-5.10/btrfs-zlib-zero-initialize-zlib-workspace.patch
new file mode 100644 (file)
index 0000000..5147d1e
--- /dev/null
+++ b/queue-5.10/btrfs-zlib-zero-initialize-zlib-workspace.patch
@@ -0,0 +1,36 @@
+From eadd7deca0ad8a83edb2b894d8326c78e78635d6 Mon Sep 17 00:00:00 2001
+From: Alexander Potapenko <glider@google.com>
+Date: Tue, 24 Jan 2023 12:32:34 +0100
+Subject: btrfs: zlib: zero-initialize zlib workspace
+
+From: Alexander Potapenko <glider@google.com>
+
+commit eadd7deca0ad8a83edb2b894d8326c78e78635d6 upstream.
+
+KMSAN reports uses of uninitialized memory in zlib's longest_match()
+called on memory originating from zlib_alloc_workspace().
+This issue is known by zlib maintainers and is claimed to be harmless,
+but to be on the safe side we'd better initialize the memory.
+
+Link: https://zlib.net/zlib_faq.html#faq36
+Reported-by: syzbot+14d9e7602ebdf7ec0a60@syzkaller.appspotmail.com
+CC: stable@vger.kernel.org # 5.4+
+Signed-off-by: Alexander Potapenko <glider@google.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/zlib.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/zlib.c
++++ b/fs/btrfs/zlib.c
+@@ -63,7 +63,7 @@ struct list_head *zlib_alloc_workspace(u
+ 
+       workspacesize = max(zlib_deflate_workspacesize(MAX_WBITS, MAX_MEM_LEVEL),
+                       zlib_inflate_workspacesize());
+-      workspace->strm.workspace = kvmalloc(workspacesize, GFP_KERNEL);
++      workspace->strm.workspace = kvzalloc(workspacesize, GFP_KERNEL);
+       workspace->level = level;
+       workspace->buf = NULL;
+       /*

diff --git a/queue-5.10/series b/queue-5.10/series
index 19fe783bf50a4698c4c5eb8d5f781dfe3ddcab61..031fdaed0c98c022eb72d1c27db40a68a10c6487 100644 (file)
--- a/queue-5.10/series
+++ b/queue-5.10/series
@@ -95,3 +95,5 @@ bpf-do-not-reject-when-the-stack-read-size-is-differ.patch
 iio-adc-twl6030-enable-measurement-of-vac.patch
 mm-migration-return-errno-when-isolate_huge_page-fai.patch
 migrate-hugetlb-check-for-hugetlb-shared-pmd-in-node.patch
+btrfs-limit-device-extents-to-the-device-size.patch
+btrfs-zlib-zero-initialize-zlib-workspace.patch