Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 19 Aug 2022 16:38:50 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
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>, lwn <lwn@lwn.net>
Message-ID: <1557496534.17909.1660941530779.JavaMail.zimbra@efficios.com>
Subject: [RELEASE] LTTng-ust 2.12.6 and 2.13.4 (Linux user-space tracer)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Index: BBsWiGWbzxfD3y6w1mw3EXGTI3mZlw==
Thread-Topic: LTTng-ust 2.12.6 and 2.13.4 (Linux user-space tracer)
Precedence: bulk

Hi,

This is a release announcement for the currently maintained stable
branches of the LTTng-UST project. Versions 2.12.6 and 2.13.4 are
now available.

* New in these releases:

In 2.13.4, a compile-time check that disallows using types other
than integer or pointer for tracepoint array and sequence fields
has been removed in C. This is because the check relies on pointer
arithmetic, which does not support opaque pointer types, which was
therefore a regression.

In both 2.12.6 and 2.13.4, the mechanism to get the maximum cpu
number value has been changed to not rely on sysconf(3)
_SC_NPROCESSORS_CONF, but rather use /sys/devices/system/cpu/possible
on Linux. This fixes an issue observed with recent lxc, which
caused scenarios where holes in the configured CPU list causes
the returned value to be lower than the maximum cpu number + 1.

In both 2.12.6 and 2.13.4, the function lttng_ust_ctl_duplicate_ust_object_data
now returns a negative error value, fixing a segmentation fault on error
in lttng-tools.

In both 2.12.6 and 2.13.4, spurious futex wakeups are now handled
correctly. Failure to do so did not cause any user-observable issues
other than using slightly more CPU time than strictly needed, because
this spurious wakeup would only cause an additional connection attempt
to the session daemon to fail.

Feedback is welcome,

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