lp:~lttng/lttng-modules/trunk

Created by Ubuntu LTTng and last modified
Get this branch:
bzr branch lp:~lttng/lttng-modules/trunk

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Ubuntu LTTng
Project:
lttng-modules
Status:
Development

Import details

Import Status: Failed

This branch is an import of the HEAD branch of the Git repository at git://git.lttng.org/lttng-modules.git.

The import has been suspended because it failed 5 or more times in succession.

Last successful import was .

Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 5 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-0 and finished taking 4 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-5 and finished taking 5 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 2 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 5 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-3 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-2 and finished taking 10 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 10 seconds — see the log

Updating branch...

Launchpad is processing new changes to this branch which will be available in a few minutes. Reload to see the changes.

Recent revisions

1874. By Kienan Stewart <email address hidden>

fix: mm, vmscan signatures changed in linux 6.7.0-rc1

See upstream commit:

    commit 3dfbb555c98ac55b9d911f9af0e35014b445fb41
    Author: Vlastimil Babka <email address hidden>
    Date: Thu Sep 14 15:16:39 2023 +0200

        mm, vmscan: remove ISOLATE_UNMAPPED

        This isolate_mode_t flag is effectively unused since 89f6c88a6ab4 ("mm:
        __isolate_lru_page_prepare() in isolate_migratepages_block()") as
        sc->may_unmap is now checked directly (and only node_reclaim has a mode
        that sets it to 0). The last remaining place is mm_vmscan_lru_isolate
        tracepoint for the isolate_mode parameter. That one was mainly used to
        indicate the active/inactive mode, which the trace-vmscan-postprocess.pl
        script consumed, but that got silently broken. After fixing the script by
        the previous patch, it does not need the isolate_mode anymore. So just
        remove the parameter and with that the whole ISOLATE_UNMAPPED flag.

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

1873. By Kienan Stewart <email address hidden>

fix: phys_proc_id and cpu_core_id moved in linux 6.7.0-rc1

See upstream commit:

    commit 02fb601d27a7abf60d52b21bdf5b100a8d63da3f
    Author: Thomas Gleixner <email address hidden>
    Date: Mon Aug 14 10:18:30 2023 +0200

        x86/cpu: Move phys_proc_id into topology info

        Rename it to pkg_id which is the terminology used in the kernel.

        No functional change.

See upstream commit:

    commit e95256335d45cc965cd12c423535002974313340
    Author: Thomas Gleixner <email address hidden>
    Date: Mon Aug 14 10:18:34 2023 +0200

        x86/cpu: Move cpu_core_id into topology info

        Rename it to core_id and stick it to the other ID fields.

        No functional change.

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

1872. By Kienan Stewart <email address hidden>

Fix build for RHEL 8.8 with linux 4.18.0-477.10.1+

4.18.0-477.10.1 introduces backports a change which updates the
`kfree_skb` trace event to the 3-argument version used in more recent
kernel versions.

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

1871. By Jérémie Galarneau <email address hidden>

Fix: bytecode validator: oops during validation of immediate string

Issue observed
--------------

Running Linux 6.5.5, lttng-modules @ 6be48c9f, all built with gcc
13.2.1, I got a 'BUG' in dmesg while enabling the following event
rule:

  $ lttng enable-event --kernel --syscall --channel chanK --all --filter '$ctx.procname == "UST reg*"'

The relevant parts of the 'BUG' output follow:

  [ +0.715480] detected buffer overflow in strnlen
  [ +0.000001] kernel BUG at lib/string_helpers.c:1031!
  [ +0.000008] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
  [ +0.000003] CPU: 2 PID: 157174 Comm: Client manageme Tainted: G S U OE 6.5.5-arch1-1 #1 d82a0f532dd8cfe67d5795c1738d9c01059a0c62
  [ +0.000001] RIP: 0010:fortify_panic+0x13/0x20
  [ +0.000006] Code: 41 5d c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 89 fe 48 c7 c7 90 22 c8 86 e8 3d aa b1 ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90
  [ +0.000002] RSP: 0018:ffffa7c7c106f918 EFLAGS: 00010246
  [ +0.000002] RAX: 0000000000000023 RBX: 000000000000000b RCX: 0000000000000000
  [ +0.000002] RDX: 0000000000000000 RSI: ffff92766e4a16c0 RDI: ffff92766e4a16c0
  [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffa7c7c106f7c0
  [ +0.000001] R10: 0000000000000003 R11: ffffffff874ca068 R12: ffff927618202480
  [ +0.000001] R13: ffff9276182024d2 R14: ffff927453999c08 R15: ffff9273dc7aa478
  [ +0.000001] FS: 00007f06553f9680(0000) GS:ffff92766e480000(0000) knlGS:0000000000000000
  [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [ +0.000002] CR2: 0000556d54eceaa8 CR3: 00000001ad9de002 CR4: 00000000003706e0
  [ +0.000001] Call Trace:
  [ +0.000002] <TASK>
  [ +0.000002] ? die+0x36/0x90
  [ +0.000004] ? do_trap+0xda/0x100
  [ +0.000003] ? fortify_panic+0x13/0x20
  [ +0.000002] ? do_error_trap+0x6a/0x90
  [ +0.000002] ? fortify_panic+0x13/0x20
  [ +0.000002] ? exc_invalid_op+0x50/0x70
  [ +0.000003] ? fortify_panic+0x13/0x20
  [ +0.000002] ? asm_exc_invalid_op+0x1a/0x20
  [ +0.000005] ? fortify_panic+0x13/0x20
  [ +0.000002] ? fortify_panic+0x13/0x20
  [ +0.000003] bytecode_validate_overflow+0x155/0x1f0 [lttng_tracer 759e3e4fee0e774ef575e93b67e8dc7955d0c2c2]
  [ +0.000330] lttng_bytecode_validate_load+0x32/0x1e0 [lttng_tracer 759e3e4fee0e774ef575e93b67e8dc7955d0c2c2]
  [ +0.000183] lttng_enabler_link_bytecode+0x135/0x5a0 [lttng_tracer 759e3e4fee0e774ef575e93b67e8dc7955d0c2c2]
  [ +0.000132] lttng_sync_event_list+0xef/0x650 [lttng_tracer 759e3e4fee0e774ef575e93b67e8dc7955d0c2c2]
  [ +0.000123] ? __wake_up_common+0x73/0x180
  [ +0.000004] lttng_session_enable+0x3e/0x130 [lttng_tracer 759e3e4fee0e774ef575e93b67e8dc7955d0c2c2]
  [ +0.000121] lttng_session_ioctl+0x5db/0x720 [lttng_tracer 759e3e4fee0e774ef575e93b67e8dc7955d0c2c2]
  [ +0.000120] ? __slab_free+0xf1/0x330
  [ +0.000004] ? __scm_recv_common.isra.0+0x144/0x180
  [ +0.000004] ? unix_stream_read_generic+0x233/0xb60
  [ +0.000006] __x64_sys_ioctl+0x94/0xd0
  [ +0.000004] do_syscall_64+0x5d/0x90
  [ +0.000004] ? switch_fpu_return+0x50/0xe0
  [ +0.000004] ? exit_to_user_mode_prepare+0x132/0x1e0
  [ +0.000003] ? syscall_exit_to_user_mode+0x2b/0x40
  [ +0.000002] ? do_syscall_64+0x6c/0x90
  [ +0.000003] ? do_syscall_64+0x6c/0x90
  [ +0.000002] ? do_syscall_64+0x6c/0x90
  [ +0.000002] ? do_syscall_64+0x6c/0x90
  [ +0.000002] ? syscall_exit_to_user_mode+0x2b/0x40
  [ +0.000002] ? do_syscall_64+0x6c/0x90
  [ +0.000002] ? do_syscall_64+0x6c/0x90
  [ +0.000002] ? do_syscall_64+0x6c/0x90
  [ +0.000002] ? do_syscall_64+0x6c/0x90
  [ +0.000002] ? exc_page_fault+0x7f/0x180
  [ +0.000003] entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Cause
-----

`struct load_op` has a trailing 0-length array `data` member that is
used to refer, in the context of BYTECODE_OP_LOAD_STAR_GLOB_STRING, to
an immediate string operand that follows it.

During the validation of a filtering bytecode, strnlen is properly used
to determine the size of the immediate string operand, with a `maxlen`
parameter that is used to ensure the string operand is contained within
the bytecode (see lttng-bytecode-validator.c:434).

However, recent KSPP-related changes have enabled additional overrun
checks when statically-sized and flexible arrays are used. Those are
enabled when the kernel is built with CONFIG_UBSAN_BOUNDS and/or
CONFIG_FORTIFY_SOURCE configured.

The KBUILD CFLAGS now contain `-fstrict-flex-arrays=3`, which is
recognized by gcc 13+[1] and allows proper coverage of dynamically sized
trailing arrays when those configuration options are used.

With those validations in place, the kernel assumes that the `data`
array is truly of length 0 and it BUGs to warn of an invalid access.

The commit linked above contains a number of links explaining the
rationale for transitioning uses of the trailing zero-length arrays (a
gcc extension) to C99 flexible array members (FAM).

This was discussed at this year's GNU Cauldron [2].

Solution
--------

Uses of zero-length arrays (`foo[0]`) are replaced by flexible array
members (`foo[]`). The only cases that are left untouched are those
where the zero-length array is used to indicate the end of a
structure (i.e. it doesn't indicate that a variable number of elements
follow), see the `metadata_packet_header`, `metadata_record_header`,
`event_notifier_packet_header`, and `event_notifier_record_header`
structures.

It may be desirable to use the new `counted_by` attribute for some of
those in the future (`lttng_kernel_abi_filter_bytecode`,
`lttng_kernel_abi_capture_bytecode`, and `bytecode_runtime`) [3].

Note
----

While this is tagged as a memory handling 'fix', it has no security
implication as far as I can tell. The accesses that are flagged by the
new validations were valid.

This merely allows the runtime validations to understand the memory
layout properly.

[1] https://github.com/torvalds/linux/commit/df8fc4e934c12b906d08050d7779f292b9c5c6b5
[2] https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=get&target=Most-wanted+Security+Features+in+GCC+for+Linux+Kernel.pdf
[3] https://lwn.net/Articles/930943/

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

1870. By Kienan Stewart <email address hidden>

fix: lttng-probe-kvm-x86-mmu build with linux 6.6

A small change was made upstream in `spte.h` that requires
`arch/x86/kvm` to be added to the search path when
building lttng-probe-kvm.x86-mmu.o.

See upstream commit :

  commit d10f3780bc2f80744d291e118c0c8bade54ed3b8
  Author: Sean Christopherson <email address hidden>
  Date: Tue Aug 8 15:40:59 2023 -0700

      KVM: x86/mmu: Include mmu.h in spte.h

      Explicitly include mmu.h in spte.h instead of relying on the "parent" to
      include mmu.h. spte.h references a variety of macros and variables that
      are defined/declared in mmu.h, and so including spte.h before (or instead
      of) mmu.h will result in build errors, e.g.

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

1869. By Michael Jeanson <email address hidden>

fix: built-in lttng with kernel >= v6.1

In kernel v6.1 the list of subdirectories was moved from Makefile to
Kbuild. Adjust our built-in.sh script to detect this change and use the
appropriate file to graft ourself to the kernel build system.

Thanks to Richa Bharti for the initial patch.

See upstream commit:

  commit 5750121ae7382ebac8d47ce6d68012d6cd1d7926
  Author: Masahiro Yamada <email address hidden>
  Date: Sun Sep 25 03:19:10 2022 +0900

    kbuild: list sub-directories in ./Kbuild

    Use the ordinary obj-y syntax to list subdirectories.

Change-Id: Ifc0f1bdea5ee59b0e0b96cdb31c9c689deb20559
Reported-by: Richa Bharti <email address hidden>
Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1868. By Michael Jeanson <email address hidden>

fix: ubuntu kinetic kernel range for jdb2

Kinetic introduces a 'lowlatency' kernel with a different ABI number
than the 'generic' flavor, add 2 ranges accordingly.

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

1867. By Michael Jeanson <email address hidden>

Add ordered extents tracepoints to btrfs probe

See upstream commit:

  commit 5bea2508811ec76105b01c90c1f1661024c257a9
  Author: Johannes Thumshirn <email address hidden>
  Date: Thu Jun 9 09:28:04 2022 -0700

    btrfs: add tracepoints for ordered extents

    When debugging a reference counting issue with ordered extents, I've found
    we're lacking a lot of tracepoint coverage in the ordered extent code.

    Close these gaps by adding tracepoints after every refcount_inc() in the
    ordered extent code.

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

1866. By Michael Jeanson <email address hidden>

Add support for RHEL 9.1

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

1865. By Michael Jeanson <email address hidden>

Add support for RHEL 9.0

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

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers