~lttng/lttng-ust/lttng-ust : changes

~lttng/lttng-ust/lttng-ust » Changes from revision 3059

From Revision 3058 to 3039

Rev	Summary	Authors	Date
3058	Rename "tsc" to "timestamp" Rename "tsc" to "timestamp" Naming timestamps "TSC" or "tsc" is an historical artefact dating from the implementation of libringbuffer, where the initial intent was to use the x86 "rdtsc" instruction directly, which ended up not being what was done in reality. Rename uses of "TSC" and "tsc" to "timestamp" to clarify things and don't require reviewers to be fluent in x86 instruction set. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: I8e7e2ad9cd2d2427485fc6adbc340fccde14ca2f	Mathieu Desnoyers	5 months ago
3057	docs: Correct GitHub URLs in lttng-ust.3 docs: Correct GitHub URLs in lttng-ust.3 The branches follow the format `stable-X.YZ` rather than `vX.YZ`. Furthermore, when rendering the man pages from source, the URLs were omitted completely as the subsitution `{lttng_version}` was not defined. This hasn't been an issue for the published HTML versions as those are produced via a different script in the `lttng-www` project which presumably sets the substitution properly. Change-Id: Ib96c99df13ddf724e128f95e7ce7c74b2c10c766 Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Kienan Stewart	5 months ago
3056	fix: handle EINTR correctly in get_cpu_mask_from_sysfs fix: handle EINTR correctly in get_cpu_mask_from_sysfs If the read() in get_cpu_mask_from_sysfs() fails with EINTR, the code is supposed to retry, but the while loop condition has (bytes_read > 0), which is false when read() fails with EINTR. The result is that the code exits the loop, having only read part of the string. Use (bytes_read != 0) in the while loop condition instead, since the (bytes_read < 0) case is already handled in the loop. Original fix in liburcu from Benjamin Marzinski <bmarzins@redhat.com>: commit 9922f33e2986 ("fix: handle EINTR correctly in get_cpu_mask_from_sysfs") Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: I885a0fb98e5a7cfb9a8bd180c8e64b20926ff58c	Mathieu Desnoyers	5 months ago
3055	Introduce LTTNG_UST_MAP_POPULATE_POLICY environment variable Introduce LTTNG_UST_MAP_POPULATE_POLICY environment variable Problem Statement ----------------- commit 4d4838bad480 ("Use MAP_POPULATE to reduce pagefault when available") was first introduced in tag v2.11.0 and never backported to stable branches. Its purpose was to reduce the tracer fast-path latency caused by handling minor page faults the first time a given application writes to each page of the ring buffer after mapping them. The discussion thread leading to this commit can be found here [1]. When using LTTng-UST for diagnosing real-time applications with very strict constraints, this added latency is unwanted. That commit introduced the MAP_POPULATE flag when mapping the ring buffer pages, which causes the kernel to pre-populate the page table entries (PTE). This has, however, unintended consequences for the following scenarios: * Short-lived applications which write very little to the ring buffer end up taking more time to start, because of the time it takes to pre-populate all the ring buffer pages, even though they typically won't be used by the application. * Containerized workloads using cpusets will also end up having longer application startup time than strictly required, and will populate PTE for ring buffers of CPUs which are not present in the cpuset. There are, therefore, two sets of irreconcilable requirements: short-lived and containerized workloads benefit from lazily populating the PTE, whereas real-time workloads benefit from pre-populating them. This will therefore require a tunable environment variable that will let the end-user choose the behavior for each application. Solution -------- Allow users to specify whether they want to pre-populate shared memory pages within the application with an environment variable. LTTNG_UST_MAP_POPULATE_POLICY If set, override the policy used to populate shared memory pages within the application. The expected values are: none Do not pre-populate any pages, take minor faults on first access while tracing. cpu_possible Pre-populate pages for all possible CPUs in the system, as listed by /sys/devices/system/cpu/possible. Default: none. If the policy is unknown, use the default. Choice of the default --------------------- Given that users with strict real-time constraints already have to setup their tracing with specific options (see the "--read-timer" lttng-enable-channel(3) option [2]), it makes sense that the default is to lazily populate the ring buffer PTE, and require users with real-time constraints to explicitly enable the pre-populate through an environment variable. Effect on default behavior -------------------------- The default behavior for ring buffer PTE mapping will be changing across LTTng-UST versions in the following way: - 2.10 and earlier: lazily populate PTE, - 2.11-2.13: pre-populate PTE, - 2.14: lazily populate PTE. LTTng-UST 2.14 will revert back to the 2.10 lazy populate scheme by default. [1] https://lists.lttng.org/pipermail/lttng-dev/2019-July/thread.html#29094 [2] https://lttng.org/docs/v2.13/#doc-channel-timers Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: I6743b08cd1fe0d956caaf6aad63005555bb9640e	Mathieu Desnoyers	5 months ago
3054	Add close_range wrapper to liblttng-ust-fd.so Add close_range wrapper to liblttng-ust-fd.so glibc 2.34 implements close_range(2), which is used by the ssh client (amongst others). This needs to be overridden to make sure ssh does not close lttng-ust file descriptors. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: Ic4e0046499e1f010395aec71a48316b9d1e9bf3f	Mathieu Desnoyers	5 months ago
3053	docs: Add supported versions and fix-backport policy docs: Add supported versions and fix-backport policy Change-Id: I9ec43912652fc713484959e9315765f7e9d29a3e Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Kienan Stewart	5 months ago
3052	docs: Add cases in which tracepoints in ctors/dtors may not ... docs: Add cases in which tracepoints in ctors/dtors may not work Change-Id: I52666810322e26b3841ea1bca6f588b6c3e6f3f8 Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Kienan Stewart	5 months ago
3051	ust-tracepoint-event: Add static check of sequences length t... ust-tracepoint-event: Add static check of sequences length type Enforce required unsigned type for length of sequence at compile time. Change-Id: Ia8668a80eb0c0b81e8c03b208d7581e34af313fd Signed-off-by: Olivier Dion <odion@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Olivier Dion	6 months ago
3050	lttng-ust(3): Fix wrong len_type for sequence lttng-ust(3): Fix wrong len_type for sequence `len_type' of a sequence field must be of type unsigned integer. Some provided examples in the man page were incorrectly using a type signed integer, resulting in correct compilation, but error while decoding. Change-Id: Icc685b330d0704660b36f703075f453d71c5e4cb Signed-off-by: Olivier Dion <odion@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Olivier Dion	6 months ago
3049	python: log exception details when agent thread cannot start python: log exception details when agent thread cannot start Change-Id: If9d58f066d513f63428bbc07190a956571532655 Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Kienan Stewart	7 months ago
3048	Fix: python lttngust agent fails when LTTNG_UST_APP_PATH is ... Fix: python lttngust agent fails when LTTNG_UST_APP_PATH is not set Observed issue ============== lttng-tools `tests/regression/ust/python-logging/test_python_logging` had the following failures: ``` not ok 14 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events not ok 27 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events not ok 40 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events not ok 53 - Found 0 / 5 events matching 'python-ev-test1' out of 0 events not ok 66 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events not ok 74 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events not ok 82 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events not ok 98 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events not ok 109 - Found 0 / 5 events matching 'python-ev-test1' out of 0 events not ok 115 - Found 0 events matching 'python-ev-test1' not ok 121 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events not ok 127 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events not ok 134 - Found 0 / 10 events matching 'python-ev-test1' amongst 0 events not ok 140 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events not ok 146 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events not ok 157 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events ``` Cause ===== When the use of `LTTNG_UST_APP_PATH` was introduced[1], no default value for `ust_app_port` was set. In the case where `LTTNG_UST_APP_PATH` is not set in the environment the condition for starting with the `ust_app_port` is still checked, causing the following exception: ``` [2559145.907503] LTTng-UST warning: _init_threads(): cannot create client threads: cannot access local variable 'ust_app_port' where it is not associated with a value ``` Solution ======== Provide a known default value for `ust_app_port`. Known drawbacks =============== None. References ========== [1]: https://github.com/lttng/lttng-ust/commit/c0f6fb054d2f16518d047a6adf7e8aa81eff5403 Change-Id: I92242ccd056dd91505156e4e8df812639eaef570 Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Kienan Stewart	7 months ago
3047	Add initial support for the multiple LTTNG_UST_APP_PATHs Add initial support for the multiple LTTNG_UST_APP_PATHs The `$LTTNG_UST_APP_PATH` is split using ':' as a separator. There is no provision for escaping the ':' separator. Paths after the first path will be ignored for the moment and a warning emitted. Change-Id: I619a3578e00fd3c758d616b99b443fc15a1477df Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Kienan Stewart	8 months ago
3046	Fix java client connection path when LTTNG_UST_APP_PATH is s... Fix java client connection path when LTTNG_UST_APP_PATH is set When LTTNG_UST_CTL_PATH is set for `lttng-sessiond`, the agent port is at `$LTTNG_UST_CTL_PATH/agent.port`, not `$LTTNG_UST_CTL_PATH/.lttng/agent.port`. Change-Id: I79419f36cbd802da06acd68f58e437b0d4eb3856 Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Kienan Stewart	8 months ago
3045	Introduce LTTNG_UST_APP_PATH environment variable Introduce LTTNG_UST_APP_PATH environment variable Introduce an environment to specify a path under which unix sockets used for the communication between the application (tracee) instrumented with `liblttng-ust` and the LTTng session and consumer daemons (part of the LTTng-tools project) are located. When `$LTTNG_UST_APP_PATH` is specified, only this path is considered for connecting to a session daemon. Setting this environment variable disables connection to root and per-user session daemons. The `$LTTNG_UST_APP_PATH` target directory must exist and be accessible by the user before the application is executed for tracing to work. This environment variable affects the Java and Python agents in the same way. This environment variable on the LTTng-UST application side is meant to be used with a new LTTNG_UST_CTL_PATH on the lttng sessiond side. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: I4784f4565514a9771827603bd0bebabbeb37a7ad	Mathieu Desnoyers	8 months ago
3044	Rename "global" sock_info field to "multi_user" Rename "global" sock_info field to "multi_user" Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: Ife23f632db641e476e2e059031a2f956af4da72d	Mathieu Desnoyers	8 months ago
3043	Fix: libc wrapper: use initial-exec for malloc_nesting TLS Fix: libc wrapper: use initial-exec for malloc_nesting TLS Use the initial-exec TLS model for the malloc_nesting nesting guard variable to ensure that the glibc implementation of the TLS access don't trigger infinite recursion by calling the memory allocator wrapper functions, which can happen with global-dynamic. Considering that the libc wrapper is meant to be loaded with LD_PRELOAD anyway (never with dlopen(3)), we always expect the libc to have enough space to hold the malloc_nesting variable. In addition to change the malloc_nesting from global-dynamic to initial-exec, this removes the URCU TLS compatibility layer from the libc wrapper, which is a good thing: this compatibility layer relies on pthread key and calloc internally, which makes it a bad fit for TLS accesses guarding access to malloc wrappers, due to possible infinite recursion. Link: https://lists.lttng.org/pipermail/lttng-dev/2024-January/030697.html Reported-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: I72c42bc09c1a06e2922b184b85abeb9c94200ee2	Mathieu Desnoyers	8 months ago
3042	Tests: implement REUSE with SPDX identifiers Tests: implement REUSE with SPDX identifiers The SPDX identifiers [1] are a legally binding shorthand, which can be used instead of the full boiler plate text. This is the first step towards implementing the full REUSE spec [2] to help with copyright and licensing audits and compliance. This will reduce a lot a manual work required for the licensing audit required in Debian on each update. For files that lacked copyright and licensing information, I used the following guidelines. If a clear author could be determined from the git history use it, otherwise use 'EfficiOS Inc.'. For build system files, use 'MIT', for documentation 'CC-BY-4.0' and for data files 'CC0-1.0'. Freeform text files were converted to Markdown to allow licensing comments. [1] https://spdx.org/ids-how [2] https://reuse.software/tutorial/ Change-Id: I3c391f15d97b5958bdfacc17eb4ab2abafd9d99d Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Michael Jeanson	9 months ago
3041	doc: implement REUSE with SPDX identifiers doc: implement REUSE with SPDX identifiers The SPDX identifiers [1] are a legally binding shorthand, which can be used instead of the full boiler plate text. This is the first step towards implementing the full REUSE spec [2] to help with copyright and licensing audits and compliance. This will reduce a lot a manual work required for the licensing audit required in Debian on each update. For files that lacked copyright and licensing information, I used the following guidelines. If a clear author could be determined from the git history use it, otherwise use 'EfficiOS Inc.'. For build system files, use 'MIT', for documentation 'CC-BY-4.0' and for data files 'CC0-1.0'. Freeform text files were converted to Markdown to allow licensing comments. [1] https://spdx.org/ids-how [2] https://reuse.software/tutorial/ Change-Id: Idc57357d401c4efac4d0c641108607236fa8ecd4 Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Michael Jeanson	9 months ago
3040	include: implement REUSE with SPDX identifiers include: implement REUSE with SPDX identifiers The SPDX identifiers [1] are a legally binding shorthand, which can be used instead of the full boiler plate text. This is the first step towards implementing the full REUSE spec [2] to help with copyright and licensing audits and compliance. This will reduce a lot a manual work required for the licensing audit required in Debian on each update. For files that lacked copyright and licensing information, I used the following guidelines. If a clear author could be determined from the git history use it, otherwise use 'EfficiOS Inc.'. For build system files, use 'MIT', for documentation 'CC-BY-4.0' and for data files 'CC0-1.0'. Freeform text files were converted to Markdown to allow licensing comments. [1] https://spdx.org/ids-how [2] https://reuse.software/tutorial/ Change-Id: Ie6e7d801e879f78ee34361c2327338ac8b60c92b Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Michael Jeanson	9 months ago
3039	src: implement REUSE with SPDX identifiers src: implement REUSE with SPDX identifiers The SPDX identifiers [1] are a legally binding shorthand, which can be used instead of the full boiler plate text. This is the first step towards implementing the full REUSE spec [2] to help with copyright and licensing audits and compliance. This will reduce a lot a manual work required for the licensing audit required in Debian on each update. For files that lacked copyright and licensing information, I used the following guidelines. If a clear author could be determined from the git history use it, otherwise use 'EfficiOS Inc.'. For build system files, use 'MIT', for documentation 'CC-BY-4.0' and for data files 'CC0-1.0'. Freeform text files were converted to Markdown to allow licensing comments. [1] https://spdx.org/ids-how [2] https://reuse.software/tutorial/ Change-Id: I5bebf12931a64f29fa84ee3947b165d0624db13a Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>	Michael Jeanson	9 months ago

Older »