Author: Kienan Stewart
Revision Date: 2023-11-24 15:21:38 UTC

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

See upstream commit:

    commit 3dfbb555c98ac55b9d911f9af0e35014b445fb41
    Author: Vlastimil Babka <vbabka@suse.cz>
    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 <kstewart@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ie7346886d926a1a9d20bcb1570c587c5e943a1c3

Author: Simon Marchi
Revision Date: 2023-11-22 16:55:42 UTC

lib: validate iterator message sequence

Validate that the sequence of messages produced by iterators respects
the sequence defined by the Message Interchange Protocol (MIP) [1].

    Without packets
        SB (E | DE)* SE

    With packets
        SB ((PB (E | DE)* PE) | DE | DP)* SE

Validate that when an iterator returns
BT_MESSAGE_ITERATOR_CLASS_NEXT_METHOD_STATUS_END, all streams are
properly ended (we have received a stream end message for all streams).

Add an expected_msg_types field to the iterator's per_stream_state
structure, which holds a bit mask of the message types the iterator is
allowed to emit next.

Use the cur_packet field that is maintained by
message_packet_is_valid when processing a discarded events message. We
need to know if we are in a packet or not to determine the following
valid message types (DE appears twice in the "With packets" sequence
above, once within a packet and once outside a packet).

It doesn't matter in which order the two assertions are placed, since
the "sequence is as expected" assertion doesn't use the cur_packet field
when handling the "packet beginning" and "packet end" messages.
However, I think that it is more useful to have the "sequence is as
expected" first. Some mistakes, like the following sequence where a
packet beginning message is forgotten:

    ... PB E E PE E E PE ...

... would cause both assertions to fail. But the "sequence is as
expected" assertion points closer to the root cause of the problem than
the "packet is expected" one, which points more to a symptom. So, if
both assertions would fail, I prefer that we show the "sequence is
as expected" one.

Here's an example of the error message that is printed when an error is
detected. In this case, a packet beginning message was forgotten.

    Babeltrace 2 library postcondition not satisfied.
    ------------------------------------------------------------------------
    Condition ID: `post:message-iterator-class-next-method:mip-message-sequence-is-expected`.
    Function: bt_message_iterator_class_next_method().
    ------------------------------------------------------------------------
    Error is:
    MIP message sequence is not expected: stream-addr=0x60d000001d80, stream-id=0, iterator-addr=0x611000004c80, iterator-upstream-comp-name="source.gpx.GpxSource", iterator-upstream-comp-log-level=WARNING, iterator-upstream-comp-class-type=SOURCE, iterator-upstream-comp-class-name="GpxSource", iterator-upstream-comp-class-partial-descr="", message-addr=0x607000004540, message-type=EVENT, expected-msg-types=STREAM_END|PACKET_BEGINNING
    Aborting...

[1] https://babeltrace.org/docs/v2.0/libbabeltrace2/group__api-msg.html#api-msg-seq

Change-Id: I25d3ff9b87c551dcced1ba25e0a8525f316a8050
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10450
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Author: Sam James
Revision Date: 2023-11-06 14:24:19 UTC

Fix -Walloc-size

GCC 14 introduces a new -Walloc-size included in -Wextra which gives:
```
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
workqueue.c:401:20: warning: allocation of insufficient size '1' for type 'struct urcu_workqueue_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
workqueue.c:432:14: warning: allocation of insufficient size '1' for type 'struct urcu_workqueue_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
qsbr.c:49:14: warning: allocation of insufficient size ‘1’ for type ‘struct mynode’ with size ‘40’ [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
mb.c:50:14: warning: allocation of insufficient size ‘1’ for type ‘struct mynode’ with size ‘40’ [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
membarrier.c:50:14: warning: allocation of insufficient size ‘1’ for type ‘struct mynode’ with size ‘40’ [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
signal.c:49:14: warning: allocation of insufficient size ‘1’ for type ‘struct mynode’ with size ‘40’ [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
bp.c:49:14: warning: allocation of insufficient size ‘1’ for type ‘struct mynode’ with size ‘40’ [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
```

The calloc prototype is:
```
void *calloc(size_t nmemb, size_t size);
```

So, just swap the number of members and size arguments to match the prototype, as
we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
doing anything wrong.

Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Id84ce5cf9a1b97bfa942597aa188ef6e27e7c10d

Author: Mathieu Desnoyers
Revision Date: 2023-10-20 15:57:20 UTC

Revert "Add support for LTTNG_UST_HOME"

This reverts commit 90d125c709f566f3663bf84677f100134cc618e0.

After discussion with Jeremie, we want to introduce two (not one)
environment variables:

- LTTNG_UST_APP_PATH,
- LTTNG_UST_CTL_PATH.

to accomodate use-cases where a sessiond within a container is traced by
a sessiond in the parent container. In that situation, we want the
sessiond in the parent container to access the tracee through the
LTTNG_UST_CTL_PATH, without making the unix sockets for tracing control
visible to the child container.

Therefore, remove the LTTNG_UST_HOME environment variable before it is
added into an official release.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Author: Simon Marchi
Revision Date: 2016-11-30 00:07:22 UTC

Bump version to 2.10~pre

Author: Michael Jeanson
Revision Date: 2016-04-23 14:51:52 UTC

Add libelf and libdw builddeps

Author: Christian Babeux
Revision Date: 2013-09-17 18:08:39 UTC

Tests: Add UST snapshots streaming test with custom URI

Signed-off-by: Christian Babeux <christian.babeux@efficios.com>
Signed-off-by: David Goulet <dgoulet@efficios.com>