lp:~lttng/lttng-modules/trunk

Branch merges

This import branch has no branches proposed for merge into it.

No branches dependent on this one.

Related source package recipes

1 recipe using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

1894. By Martin Hicks <email address hidden> on 2024-02-07

Compile fixes for RHEL 9.3 kernels

The ranges were build tested on RHEL9.2 (5.14.0-284.11.1), RHEL9.3
(5.14.0-362.8.1) and RHEL8.9 (4.18.0-513.11.1).

This disables the kmem and compaction modules. I don't believe getting
these to compile will be easy, as the required struct declarations are
in vmlinux.h, and haven't been moved into mm/internal.h and mm/slab.h in
the RHEL sources.

Change-Id: I999c593d6850e2327f6e9df8432a4ea2325a7cea
Signed-off-by: Martin Hicks <email address hidden>
Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1893. By Kienan Stewart <email address hidden> on 2024-02-07

Fix: ext4_discard_preallocations changed in linux 6.8.0-rc3

See upstream commit:

    commit f0e54b6087de9571ec61c189d6c378b81edbe3b2
    Author: Kemeng Shi <email address hidden>
    Date: Fri Jan 5 17:21:02 2024 +0800

        ext4: remove 'needed' in trace_ext4_discard_preallocations

        As 'needed' to trace_ext4_discard_preallocations is always 0 which
        is meaningless. Just remove it.

Change-Id: Ib6b698ca553c4beebd4ca791c83bbbb927901758
Signed-off-by: Kienan Stewart <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1892. By Jérémie Galarneau <email address hidden> on 2024-02-05

Clean-up: rb: backend.h: remove extra newline

Signed-off-by: Jérémie Galarneau <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: Iaf749728feb1b3e790091af84fa09739bf1b50f8

1891. By Kienan Stewart <email address hidden> on 2024-02-02

Remove strlcpy usage

The replacement for `strlcpy`, `strscpy`, was introduced in Linux
4.3. As lttng-modules master aims to support Linux 4.4+ at this time,
the version check can safely be removed.

See upstream commit:

    commit 30035e45753b708e7d47a98398500ca005e02b86
    Author: Chris Metcalf <email address hidden>
    Date: Wed Apr 29 12:52:04 2015 -0400

        string: provide strscpy()

        The strscpy() API is intended to be used instead of strlcpy(),
        and instead of most uses of strncpy().

        - Unlike strlcpy(), it doesn't read from memory beyond (src + size).

        - Unlike strlcpy() or strncpy(), the API provides an easy way to check
          for destination buffer overflow: an -E2BIG error return value.

        - The provided implementation is robust in the face of the source
          buffer being asynchronously changed during the copy, unlike the
          current implementation of strlcpy().

        - Unlike strncpy(), the destination buffer will be NUL-terminated
          if the string in the source buffer is too long.

        - Also unlike strncpy(), the destination buffer will not be updated
          beyond the NUL termination, avoiding strncpy's behavior of zeroing
          the entire tail end of the destination buffer. (A memset() after
          the strscpy() can be used if this behavior is desired.)

        - The implementation should be reasonably performant on all
          platforms since it uses the asm/word-at-a-time.h API rather than
          simple byte copy. Kernel-to-kernel string copy is not considered
          to be performance critical in any case.

Change-Id: I31fefde148d5b63a30532fbcb4b59bb951bba902
Signed-off-by: Kienan Stewart <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1890. By Kienan Stewart <email address hidden> on 2024-02-02

Fix: btrfs_get_extent flags and compress_type changed in linux 6.8.0-rc1

See upstream commit:

    commit f86f7a75e2fb5fd7d31d00eab8a392f97ba42ce9
    Author: Filipe Manana <email address hidden>
    Date: Mon Dec 4 16:20:33 2023 +0000

        btrfs: use the flags of an extent map to identify the compression type

        Currently, in struct extent_map, we use an unsigned int (32 bits) to
        identify the compression type of an extent and an unsigned long (64 bits
        on a 64 bits platform, 32 bits otherwise) for flags. We are only using
        6 different flags, so an unsigned long is excessive and we can use flags
        to identify the compression type instead of using a dedicated 32 bits
        field.

        We can easily have tens or hundreds of thousands (or more) of extent maps
        on busy and large filesystems, specially with compression enabled or many
        or large files with tons of small extents. So it's convenient to have the
        extent_map structure as small as possible in order to use less memory.

        So remove the compression type field from struct extent_map, use flags
        to identify the compression type and shorten the flags field from an
        unsigned long to a u32. This saves 8 bytes (on 64 bits platforms) and
        reduces the size of the structure from 136 bytes down to 128 bytes, using
        now only two cache lines, and increases the number of extent maps we can
        have per 4K page from 30 to 32. By using a u32 for the flags instead of
        an unsigned long, we no longer use test_bit(), set_bit() and clear_bit(),
        but that level of atomicity is not needed as most flags are never cleared
        once set (before adding an extent map to the tree), and the ones that can
        be cleared or set after an extent map is added to the tree, are always
        performed while holding the write lock on the extent map tree, while the
        reader holds a lock on the tree or tests for a flag that never changes
        once the extent map is in the tree (such as compression flags).

Change-Id: I95402d43f064c016b423b48652e4968d3db9b8a9
Signed-off-by: Kienan Stewart <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1889. By Kienan Stewart <email address hidden> on 2024-02-02

Fix: btrfs_chunk tracepoints changed in linux 6.8.0-rc1

See upstream commit:

    commit 7dc66abb5a47778d7db327783a0ba172b8cff0b5
    Author: Filipe Manana <email address hidden>
    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 <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1888. By Kienan Stewart <email address hidden> on 2024-02-02

Fix: strlcpy removed in linux 6.8.0-rc1

See upstream commit:

    commit d26270061ae66b915138af7cd73ca6f8b85e6b44
    Author: Kees Cook <email address hidden>
    Date: Thu Jan 18 12:31:55 2024 -0800

        string: Remove strlcpy()

        With all the users of strlcpy() removed[1] from the kernel, remove the
        API, self-tests, and other references. Leave mentions in Documentation
        (about its deprecation), and in checkpatch.pl (to help migrate host-only
        tools/ usage). Long live strscpy().

The replacement interface, `strscpy`, has been available since linux
4.3, introduced in the upstream commit
30c44659f4a3e7e1f9f47e895591b4b40bf62671.

As lttng-modules master branch targets linux 4.4+ at this time,
`strlcpy` can be replaced with `strscpy`.

Change-Id: I27cdff70a504b25340cc59150ed8e959d9629e43
Signed-off-by: Kienan Stewart <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1887. By Kienan Stewart <email address hidden> on 2024-02-02

Fix: timer_start changed in linux 6.8.0-rc1

See upstream commit

    commit dbcdcb62b59db2cf6a24113873b90da15c6f0b19
    Author: Anna-Maria Behnsen <email address hidden>
    Date: Fri Dec 1 10:26:26 2023 +0100

        tracing/timers: Enhance timer_start tracepoint

        For starting a timer, the timer is enqueued into a bucket of the timer
        wheel. The bucket expiry is the defacto expiry of the timer but it is not
        equal the timer expiry because of increasing granularity when bucket is in
        a higher level of the wheel. To be able to figure out in a trace whether a
        timer expired in time or not, the bucket expiry time is required as well.

        Add bucket expiry time to the timer_start tracepoint and thereby simplify
        the arguments.

Change-Id: I4868092765745b1efd0c48f13c0b837f2007dcb6
Signed-off-by: Kienan Stewart <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1886. By Kienan Stewart <email address hidden> on 2024-02-02

Fix: sched_stat_runtime changed in linux 6.8.0-rc1

See upstream commit:

    commit 5fe6ec8f6ab549b6422e41551abb51802bd48bc7
    Author: Peter Zijlstra <email address hidden>
    Date: Mon Nov 6 13:41:43 2023 +0100

        sched: Remove vruntime from trace_sched_stat_runtime()

        Tracing the runtime delta makes sense, observer can sum over time.
        Tracing the absolute vruntime makes less sense, inconsistent:
        absolute-vs-delta, but also vruntime delta can be computed from
        runtime delta.

        Removing the vruntime thing also makes the two tracepoint sites
        identical, allowing to unify the code in a later patch.

Change-Id: I24ebb4e06dbb646a1af75ac62b74f3821ff197de
Signed-off-by: Kienan Stewart <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1885. By Kienan Stewart <email address hidden> on 2024-01-10

docs: Add links to project resources

Indicate that Gerrit (https://review.lttng.org) is the principal place
where patches are submitted and reviewed, rather than the mailing list.

Based on feedback received on the mailing list:
https://lists.lttng.org/pipermail/lttng-dev/2023-November/030670.html

Change-Id: I611deeec26393fc25c9a103c022687198100df0c
Signed-off-by: Kienan Stewart <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>