lttng-dev.lists.lttng.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: lttng-dev <lttng-dev@lists.lttng.org>,
	 Diamon discuss <diamon-discuss@lists.linuxfoundation.org>,
	 linux-trace-users <linux-trace-users@vger.kernel.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Cc: Genevieve Bastien <gbastien+lttng@versatic.net>
Subject: Re: [lttng-dev] [RELEASE] LTTng-modules 2.11.9 and 2.12.6 (Linux kernel tracer)
Date: Fri, 14 May 2021 16:16:43 -0400 (EDT)	[thread overview]
Message-ID: <1811223777.46126.1621023403092.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <1336422991.46023.1621021967687.JavaMail.zimbra@efficios.com>

----- On May 14, 2021, at 3:52 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:

> Hi,
> 
> The 2.11.9 and 2.12.6 releases of the LTTng kernel tracer are the latest bug fix
> releases
> of the 2.11 and 2.12 stable branches of the LTTng modules project.
> 
> There are a few minor bug fixes, but those are the noteworthy changes:
> 
> - Support for 5.12 Linux kernels,
> - Support recent stable kernel branches 4.14, 4.19, 5.4,
> - Support for newer Ubuntu 4.15, 5.4 and RHEL 8.2/8.3 kernels,
> - Fix: increment buffer offset when failing to copy from user-space:
> 
>    Upon failure to copy from user-space due to failing access ok check, the
>    ring buffer offset is not incremented, which could generate unreadable
>    traces because we don't account for the padding we write into the ring
>    buffer.
>    
>    Note that this typically won't affect a common use-case of copying
>    strings from user-space, because unless mprotect is invoked within a
>    narrow race window (between user strlen and user strcpy), the strlen
>    will fail on access ok when calculating the space to reserve, which will
>    match what happens on strcpy.

There is one additional noteworthy set of changes in lttng-modules 2.12.6:

        * Disable block rwbs bitwise enum in default build
        * Disable sched_switch bitwise enum in default build
        * Add experimental bitwise enum config option

The block rwbs bitwise enum and sched switch bitwise enum were introduced late
in the 2.12 rc cycle, and ended up producing traces which were not strictly
conformant with the CTF 1.8 specifications: they were producing enumerations
with values associated with no known labels.

This causes Babeltrace 1 and 2, with default options, to generate warnings when
viewing kernel traces.

So those commits introduce a new build-time option which can optionally enable
those bitwise enumerations, e.g.:

 make CONFIG_LTTNG_EXPERIMENTAL_BITWISE_ENUM=y

So until we finalize the CTF2 specification and its implementation in the tracers
and trace viewers, this provides a way for experimental users of LTTng-modules to
keep generating those bitwise enumerations without producing warnings in the
default use-case.

Without this option, a simple integer field is emitted in the trace rather than a
bitwise enumeration.

Thanks,

Mathieu


> 
> Thanks,
> 
> Mathieu
> 
> Project website: https://lttng.org
> Documentation: https://lttng.org/docs
> Download link: https://lttng.org/download
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

      reply	other threads:[~2021-05-14 20:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 19:52 [lttng-dev] [RELEASE] LTTng-modules 2.11.9 and 2.12.6 (Linux kernel tracer) Mathieu Desnoyers via lttng-dev
2021-05-14 20:16 ` Mathieu Desnoyers via lttng-dev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1811223777.46126.1621023403092.JavaMail.zimbra@efficios.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=diamon-discuss@lists.linuxfoundation.org \
    --cc=gbastien+lttng@versatic.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-users@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).