1 files changed, 124 insertions, 0 deletions

diff --git a/meta/recipes-kernel/lttng/lttng-modules/0004-Fix-btrfs_chunk-tracepoints-changed-in-linux-6.8.0-r.patch b/meta/recipes-kernel/lttng/lttng-modules/0004-Fix-btrfs_chunk-tracepoints-changed-in-linux-6.8.0-r.patch
new file mode 100644
index 0000000000..c9b1af37c8
--- /dev/null
+++ b/meta/recipes-kernel/lttng/lttng-modules/0004-Fix-btrfs_chunk-tracepoints-changed-in-linux-6.8.0-r.patch
@@ -0,0 +1,124 @@
+From c8198382fe1cede3e16aae9978642a113a217e4c Mon Sep 17 00:00:00 2001
+From: Kienan Stewart <kstewart@efficios.com>
+Date: Mon, 22 Jan 2024 12:17:33 -0500
+Subject: [PATCH 4/5] Fix: btrfs_chunk tracepoints changed in linux 6.8.0-rc1
+
+See upstream commit:
+
+    commit 7dc66abb5a47778d7db327783a0ba172b8cff0b5
+    Author: Filipe Manana <fdmanana@suse.com>
+    Date:   Tue Nov 21 13:38:38 2023 +0000
+
+        btrfs: use a dedicated data structure for chunk maps
+
+        Currently we abuse the extent_map structure for two purposes:
+
+        1) To actually represent extents for inodes;
+        2) To represent chunk mappings.
+
+        This is odd and has several disadvantages:
+
+        1) To create a chunk map, we need to do two memory allocations: one for
+           an extent_map structure and another one for a map_lookup structure, so
+           more potential for an allocation failure and more complicated code to
+           manage and link two structures;
+
+        2) For a chunk map we actually only use 3 fields (24 bytes) of the
+           respective extent map structure: the 'start' field to have the logical
+           start address of the chunk, the 'len' field to have the chunk's size,
+           and the 'orig_block_len' field to contain the chunk's stripe size.
+
+           Besides wasting a memory, it's also odd and not intuitive at all to
+           have the stripe size in a field named 'orig_block_len'.
+
+           We are also using 'block_len' of the extent_map structure to contain
+           the chunk size, so we have 2 fields for the same value, 'len' and
+           'block_len', which is pointless;
+
+        3) When an extent map is associated to a chunk mapping, we set the bit
+           EXTENT_FLAG_FS_MAPPING on its flags and then make its member named
+           'map_lookup' point to the associated map_lookup structure. This means
+           that for an extent map associated to an inode extent, we are not using
+           this 'map_lookup' pointer, so wasting 8 bytes (on a 64 bits platform);
+
+        4) Extent maps associated to a chunk mapping are never merged or split so
+           it's pointless to use the existing extent map infrastructure.
+
+        So add a dedicated data structure named 'btrfs_chunk_map' to represent
+        chunk mappings, this is basically the existing map_lookup structure with
+        some extra fields:
+
+        1) 'start' to contain the chunk logical address;
+        2) 'chunk_len' to contain the chunk's length;
+        3) 'stripe_size' for the stripe size;
+        4) 'rb_node' for insertion into a rb tree;
+        5) 'refs' for reference counting.
+
+        This way we do a single memory allocation for chunk mappings and we don't
+        waste memory for them with unused/unnecessary fields from an extent_map.
+
+        We also save 8 bytes from the extent_map structure by removing the
+        'map_lookup' pointer, so the size of struct extent_map is reduced from
+        144 bytes down to 136 bytes, and we can now have 30 extents map per 4K
+        page instead of 28.
+
+Upstream-Status: Backport [Uhttps://review.lttng.org/c/lttng-modules/+/11700]
+
+Change-Id: Ie52b5ac83df4bc6abeb84d958c4f5d24ae0d8c75
+Signed-off-by: Kienan Stewart <kstewart@efficios.com>
+Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
+---
+ include/instrumentation/events/btrfs.h | 37 +++++++++++++++++++++++++-
+ 1 file changed, 36 insertions(+), 1 deletion(-)
+
+diff --git a/include/instrumentation/events/btrfs.h b/include/instrumentation/events/btrfs.h
+index 7c7b9b0..a2a412b 100644
+--- a/include/instrumentation/events/btrfs.h
++++ b/include/instrumentation/events/btrfs.h
+@@ -1609,7 +1609,42 @@ LTTNG_TRACEPOINT_EVENT(btrfs_delayed_ref_head,
+ )
+ #endif
+ 
+-#if (LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(4,14,0))
++#if (LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(6,8,0))
++
++LTTNG_TRACEPOINT_EVENT_CLASS(btrfs__chunk,
++
++       TP_PROTO(const struct btrfs_fs_info *fs_info, const struct btrfs_chunk_map *map,
++                u64 offset, u64 size),
++
++       TP_ARGS(fs_info, map, offset, size),
++
++       TP_FIELDS(
++               ctf_integer(int, num_stripes, map->num_stripes)
++               ctf_integer(u64, type, map->type)
++               ctf_integer(int, sub_stripes, map->sub_stripes)
++               ctf_integer(u64, offset, offset)
++               ctf_integer(u64, size, size)
++               ctf_integer(u64, root_objectid, fs_info->chunk_root->root_key.objectid)
++       )
++)
++
++LTTNG_TRACEPOINT_EVENT_INSTANCE(btrfs__chunk,  btrfs_chunk_alloc,
++
++       TP_PROTO(const struct btrfs_fs_info *fs_info, const struct btrfs_chunk_map *map,
++                u64 offset, u64 size),
++
++       TP_ARGS(fs_info, map, offset, size)
++)
++
++LTTNG_TRACEPOINT_EVENT_INSTANCE(btrfs__chunk,  btrfs_chunk_free,
++
++       TP_PROTO(const struct btrfs_fs_info *fs_info, const struct btrfs_chunk_map *map,
++                u64 offset, u64 size),
++
++       TP_ARGS(fs_info, map, offset, size)
++)
++
++#elif (LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(4,14,0))
+ 
+ LTTNG_TRACEPOINT_EVENT_CLASS(btrfs__chunk,
+ 
+-- 
+2.39.2
+