lp:~lttng/lttng-modules/trunk

Branch merges

Related source package recipes

1 recipe using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

1375. By Michael Jeanson <email address hidden> on 2020-08-13

Namespace all logging statements

Add the 'LTTng:' prefix to all our logging statements to easily
distinguish them from other kernel messages.

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

1374. By Ben on 2020-08-13

Kconfig: fix dependency issue when building in-tree without CONFIG_FTRACE

When building in-tree, one could disable CONFIG_FTRACE from kernel
config which will leave CONFIG_TRACEPOINTS selected by LTTNG modules,
but generate a lot of linker errors like below because it leaves out
other stuff, e.g.:

trace.c:(.text+0xd86b): undefined reference to `trace_event_buffer_reserve'
ld: trace.c:(.text+0xd8de): undefined reference to `trace_event_buffer_commit'
ld: trace.c:(.text+0xd926): undefined reference to `event_triggers_call'
ld: trace.c:(.text+0xd942): undefined reference to `trace_event_ignore_this_pid'
ld: net/mac80211/trace.o: in function `trace_event_raw_event_drv_tdls_cancel_channel_switch':

It appears to be caused by the fact that TRACE_EVENT macros in the Linux
kernel depend on the Ftrace ring buffer as soon as CONFIG_TRACEPOINTS is
enabled.

Steps to reproduce:

- Get a clone of an upstream stable kernel and use scripts/built-in.sh on it

- Configure a standard x86-64 build, enable built-in LTTNG but disable
  CONFIG_FTRACE from Kernel Hacking-->Tracers using menuconfig

- Build will fail at linking stage

Signed-off-by: Beniamin Sandu <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1373. By Francis Deslauriers <email address hidden> on 2020-08-06

Fix: mmap enum flags build failures

Some of the mmap option flags are not available on all architectures and
are defined to zero by include/linux/mman.h. This is probably done as a
way to no-op the use of these flags on configurations that don't support
them.
To fix this, only define these flags in our enumeration if they are
defined and non-zero.

Also, the MAP_HUGE_{2MB,1GB} labels were mistakingly named
MAP_HUGETLB_{2MB,1GB}.

Signed-off-by: Francis Deslauriers <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I778a52a0da9da6e04231a52c7f68a22d122dfb83

1372. By Francis Deslauriers <email address hidden> on 2020-08-05

syscalls: Make mmap()'s fields `prot` and `flags` enums

The `prot` flags is a simple CTF enumeration.

The `flags` field is a CTF struct of 2 CTF enumerations (`type` and
`options`). This is needed to express the two parts of this integer
flag. The 4 least significant bits of the integer are reserved to
express the type of the mapping (MAP_SHARED=0x1, MAP_PRIVATE=0x2, and
MAP_SHARED_VALIDATE=0x3).

The remaining 28 bits are used to specify optional configurations on the
mapping. As opposed to the type part, the options part is bit flag
field where all values are power of 2. This part can be expressed as
ORed bit flag values.

Signed-off-by: Francis Deslauriers <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I5ae78754b5863b31d9a3ba1b1173502e1ae284d3

1371. By Francis Deslauriers <email address hidden> on 2020-08-05

x86: add error code enum to pagefault tracepoints

Signed-off-by: Francis Deslauriers <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: Ia939eccd1a918958f6a281595e447f33da2d64f7

1370. By Michael Jeanson <email address hidden> on 2020-07-20

Fix: TAINT_UNSAFE_SMP renamed to TAINT_CPU_OUT_OF_SPEC in v3.15

See upstream commit:

  commit 8c90487cdc64847b4fdd812ab3047f426fec4d13
  Author: Dave Jones <email address hidden>
  Date: Wed Feb 26 10:49:49 2014 -0500

    Rename TAINT_UNSAFE_SMP to TAINT_CPU_OUT_OF_SPEC

    Rename TAINT_UNSAFE_SMP to TAINT_CPU_OUT_OF_SPEC, so we can repurpose
    the flag to encompass a wider range of pushing the CPU beyond its
    warrany.

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

1369. By Francis Deslauriers <email address hidden> on 2020-07-18

module_load: change `taints` field to `ctf_enum`

Signed-off-by: Francis Deslauriers <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I67b5aad0bd2bc43e06a5708f0f5e1fea56f31436

1368. By Mathieu Desnoyers on 2020-07-13

Fix: Lock metadata cache on session destroy

commit 92143b2c5656 ("Fix: metadata stream leak, missing list removal and locking")
missed taking a lock protecting the metadata stream list iteration on
session destroy. This opens a race window between iteration and item
removal/free which triggers kernel OOPS.

Signed-off-by: Mathieu Desnoyers <email address hidden>

1367. By Mathieu Desnoyers on 2020-07-10

Fix: metadata stream leak, missing list removal and locking

The metadata stream is part of a list of metadata streams in the
metadata cache. Its addition to the list should be protected by
the metadata cache lock. It needs to be paired with protection
of list iteration with the same lock.

Removal from the list is entirely missing, and should be added
to lttng_metadata_ring_buffer_release (with proper locking).

This missing list removal was probably not causing issues because the
metadata stream structure was leaked: a kfree() is missing from
lttng_metadata_ring_buffer_release as well.

Signed-off-by: Mathieu Desnoyers <email address hidden>

1366. By Mathieu Desnoyers on 2020-07-10

Fix: coherent state not changed atomically with metadata written

commit 122c63cb4310 ("Fix: Implement RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK")
introduces a new ioctl which returns a flag indicating whether the
metadata is in consistent state at the end of the sub-buffer.

That commit is meant to address metadata consistency issues observable
in live sessions.

However, the "consistent" state is false as soon as a producer is
active (between an outermost metadata_begin/end pair). Unfortunately,
if the last "RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK" operation is
done between the last metadata printf and "end" of the transaction, the
last consistency state will be false, and the consumer daemon will never
send metadata to the relay daemon. This in turn causes a live viewer to
wait for metadata endlessly.

This issue can be reproduced by running lttng-tools:
tests/regression/tools/live/test_kernel

as root in a loop.

We observe two things:
1) the poll operation blocks when there is no more metadata to send,
   which means there is no mean to unblock when the consistency state
   changes back to "true" without producing additional metadata,

2) Even if (1) was fixed, the expectation from an ABI perspective is
   that the "coherent" state is only populated when
   RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK succeeds. Therefore,
   there is no way to let user-space know about conherency transition
   unless additional metadata is generated.

Fixing this requires to hold the metadata cache lock across the entire
production of a coherent metadata transaction. This simpler scheme is
possible because the metadata is generated in a reallocated memory area
and not directly into a ring buffer anymore. This was not the case in
earlier lttng-modules versions, when the metadata was generated directly
into a ring buffer, which explains why this simpler scheme was not
implemented.

Signed-off-by: Mathieu Desnoyers <email address hidden>