Sync from SUSE:SLFO:Main lttng-modules revision 52c84b09215a240a107b89877c984f3e

This commit is contained in:
Adrian Schröter 2024-08-26 18:06:11 +02:00
parent 084716cf66
commit 48d140a854
3 changed files with 136 additions and 0 deletions

View File

@ -0,0 +1,120 @@
From: Kienan Stewart <kstewart@efficios.com>
Date: Mon Jan 22 12:17:33 2024 -0500
Subject: Fix: btrfs_chunk tracepoints changed in linux 6.8.0-rc1
References: bsc#1229151
Git-commit: 8d19592744d1bbdb9ff58c52ed142008ca1fe145
Signed-off-by: Tony Jones <tonyj@suse.de>
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.
Change-Id: Ie52b5ac83df4bc6abeb84d958c4f5d24ae0d8c75
Signed-off-by: Kienan Stewart <kstewart@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
diff --git a/include/instrumentation/events/btrfs.h b/include/instrumentation/events/btrfs.h
index 7c7b9b0c..a2a412b1 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) || defined(CONFIG_SUSE_KERNEL))
+
+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,

View File

@ -1,3 +1,14 @@
-------------------------------------------------------------------
Sun Aug 25 18:59:51 UTC 2024 - Tony Jones <tonyj@suse.com>
- kernel-source was not included in %kernel_module_package_buildreqs
so btrfs lttng tracepoints were not being enabled explaining why
build failures were only being seen for kernel-source-rt.
Add explicit BuildRequires: kernel-source
- fix build error caused by btrfs kernel tracepoint change (bsc#1229151)
New patch: fix-btrfs_chunk-tracepoints-changed-in-linux-6.8.0-rc1.patch
-------------------------------------------------------------------
Mon Feb 5 21:30:51 UTC 2024 - Tony Jones <tonyj@suse.com>

View File

@ -36,7 +36,12 @@ Source2: %{name}.keyring
Source3: %{name}-preamble
Source4: Module.supported
Patch1: fix-btrfs_chunk-tracepoints-changed-in-linux-6.8.0-rc1.patch
BuildRequires: %kernel_module_package_buildreqs
# kernel_module_package_buildreqs doesn't include kernel-source which limits
# LTTng features. So manually add it.
BuildRequires: kernel-source
%if 0%{?buildrt} == 1
BuildRequires: kernel-syms-rt
BuildRequires: kernel-source-rt