EfficiOS backport 2.9 revision 9

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: If22fb1c592907f1a8edcaa5c6e912938b4db5d27

CUSTOM: relayd protocol: ignore reply on relayd_send_index and relayd_send_close_stream

Note: this patch is not a bugfix, it is a targeted modification to
improve timing and predictability for particular scenarios.

Note: this patch only applies to userspace tracing.

Part of this work might find itself upstream but most probably not in
this form. Deeper work should be done upstream to mitigate the real root
of the problem which is how the network protocol for live works and
lifetime management of the different component required for the live
feature.

Scenario:
=======
   System with high CPU resource restriction (base high workload 99% cpu load),
   High CPU count (32),
   Slowish network (ping ~60-100ms),
   Timing constraint for create, configure, start, stop , destroy , create ... cycles.

A lot of time is wasted waiting for response that do not provide more
information and are essentially not pertinent. Here the focus is done on
the reply for relayd_send_index and relayd_send_close_stream.

relayd_send_index is used at the end of a buffer consumption and do not
require further protocol synchronization on lttng-sessiond side. This
allows us to simply mark the bytes of the response as `to ignore` on the
next real receive operation.

relayd_send_index is also used to send empty index during the live
timer. Again there is now direct value in waiting for the reply here
since tcp guarantee send/receive ordering.

relayd_send_close_stream again does not benefit from waiting on the
reply considering that even in the possibility of error there is not
much we can do since we are closing it on lttng-sessiond side.

NOTE:
   Three call sites are responsible for "purging" the unwanted reply:
   recv_reply, recv_reply_ignore and relayd_close.

   recv_reply simply try to receive all bytes to ignore at the time it
   is called. This is to preserve the protocol integrity.

   recv_reply_ignore will issue a recv call if a cutoff for `bytes to
   ignore` (128 currently) is met. The recv call will recv and discard
   the hald the quantity of the cutoff (64 in this patch). This ensure
   that long period with no real receive operation do not lead to buffer
   bloat. We slowly consume data that is "useless". The amount we
   receive is totally arbitrary and is only set to half of the cutoff to
   `give a chance to the runner` since there is a high probability that
   they are available. In any case, we block if it is not the case.

   relayd_close must wait for all `ignored bytes` to ensure that we do
   not close the socket before the relayd have sent all its reply.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I5da9b364c73498e8c0156c71960432229932ecb5

CUSTOM: consumer: ust: relayd: perform 2 stage relay_add_stream

Note: this patch is not a bugfix, it is a targeted modification to
improve timing and predictability for particular scenarios.

Note: this patch only applies to userspace tracing.

Part of this work might find itself upstream but most probably not in
this form. Deeper work should be done upstream to mitigate the real root
of the problem which is how the network protocol for lttng-live works and
lifetime management of the different component required for the live
feature.

Scenario
=======
   System with high CPU resource restriction (base high workload 99% cpu load),
   High CPU count (32),
   Slowish network (ping ~60-100ms),
   Timing constraint for create, configure, start, stop , destroy , create ... cycles.

A lot of time (3s) is wasted in the iteration loop of stream creation.
The consumer sendis the add_stream command for a single stream then wait
for a reply containing the stream id. Then the next stream is treated.

What can be done is to split this operation in two iteration/phase.
The send and receive phase. TCP guarantee ordering of send/recv call.
Thus, we can iterate over the stream and perform the send part. Then
iterate over the stream again to perform the receive part.

This could lead to deadlock in certain scenario were the receiving end
(lttng-relayd) have a small send buffer and receive buffer and we end up
blocking on the send phase on the relayd side.  This is more that likely
not applicable to our current use case since the reply from lttng-relayd
are ~4 bytes long. For 32 streams, we are talking about 128 bytes of
data to receive. This mostly disqualify this solution for upstream as-is
since we would need to validate these scenarios further. Async
communication can ease all this (either on lttng-relayd side or
lttng-sessiond), still a lot more work should be put into this for
direct upstreaming.

Still, it is good enough for our current usage pattern.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I3c74fd8086230b753684fc6d8a67348f839011b0

CUSTOM: liver timer: immediate liver timer control on data pending and destroy

Note: this patch is not a bugfix, it is a targeted modification to
improve timing and predictability for particular scenarios.

Note: this patch only applies to userspace tracing.

Part of this work might find itself upstream but most probably not in
this form. Deeper work should be done upstream to mitigate the real root
of the problem which is how the network protocol for live works and
lifetime management of the different component required for the live
feature.

Scenario #1:
=======
   System with high CPU resource restriction (base high workload 99% cpu load),
   High CPU count (32),
   Slowish network (ping ~60-100ms),
   Timing constraint for create, configure, start, stop , destroy , create ... cycles.

We see additional delay in the second cycles at the configure step
(enable channel). This delay seems to be the result of the execution of
a live timer iteration for the previously destroyed session (cycle N
-1).

The live timer for the N - 1 session is still present since it is only
stopped lazily after all associated streams are destroyed
(consumer_del_channel, unref_channel, consumer_stream_destroy,
consumer_del_stream, consumer_thread_data_poll).

To help this situation, stop the live timer on cmd_destroy. The live
timer does not have any real value for a session to be destroyed and ,in
most case, already stopped.

Scenario #2
======
   System with high CPU resource restriction (base high workload 99% cpu load),
   High CPU count (32),
   Slowish network (ping ~60-100ms).

The data pending phase can be aggravated by the live timer depending on
the network and CPU contention.

In the context of stable 2.9 and live reading, stopping the live timer
during the data pending phase of a stop command does not impact
functionality at the reader level for a single session. Note that for
stable 2.9 and as of lttng 2.13 a reader cannot hook itself on multiple
sessions. Hence stopping the live timer during the data pending stage
and starting it back does not have any foreseeable downside.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: Icf8ff6fa72b24ce221cdf866d134ee42f64c9291

Fix working directory test

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I89a4b3856a6d1756b086ef2d06ad9aa4c1d8d37b

EfficiOS backport 2.9 revision 8

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: Ic742e3107d3aad31ebe180b81faffb31637ce4eb

Fix: consumerd: uninitialized written_bytes on no-data sleep

e66d26f51 introduces a jump to a label which causes `written_bytes`
(the return value) to not be initialized.

written_bytes may be used uninitialized in this function [-Wmaybe-uninitialized]

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I72c5c07298093f27fa72b72cb157ce4eedb81adb

Build fix: consumerd misnamed label

`sleep_stream` label was changed from `stream_sleep` as part of
a fixup/rebase which didn't make it into the master branch.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ifd257e2b6d1f522d018cf0284a89f49a92b12b02

consumerd: on_sleep not called on stream when no data is available

The `on_sleep` stream operation is not invoked when a stream's `get`
operation returns ENODATA (no data available).

Since this is not an error, the normal steps of the consumption loops
should be assumed.

Not marked as a fix as this is not problematic right now. However, it
could prove misleading in the future.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I0812e3af4c967390ebba4128781787abf45c76a1

Cherry-pick difference: merge conflict on rotation. Simply deleted the
rotation related code.

Change-Id: Ic840361477d77eae387573a1bb0949636abe9b12

Fix: invalid discarded events on start/stop without event production

Observed issue
==============

On consecutive start/stop command sequence the reported discarded event
count is N * CPU, where N is the number of start/stop pair executed.

Note that no event generation occurred between each start/stop pair.

    lttng start
    lttng stop
    Tracing stopped for session auto-20200616-094338
    lttng start
    lttng stop
    Waiting for data availability
    Warning: 4 events were discarded, please refer to the documentation on channel configuration.
    Tracing stopped for session auto-20200616-094338
    lttng start
    lttng stop
    Waiting for data availability
    Warning: 8 events were discarded, please refer to the documentation on channel configuration.
    Tracing stopped for session auto-20200616-094338

The issue was bisected down to:
  commit 6f9449c22eef59294cf1e1dc3610a5cbf14baec0 (HEAD)
  Author: Jérémie Galarneau <jeremie.galarneau@efficios.com>
  Date:   Sun May 10 18:00:26 2020 -0400

  consumerd: refactor: split read_subbuf into sub-operations
  [...]

Cause
=====

The discarded event local variable, in `consumer_stream_update_stats()`
is initialized with the subbuffer sequence count instead of the
subbuffer discarded event count.

Solution
========

Use the subbuffer discarded event count to initialized the variable.

Known drawbacks
=========

None

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I5ff213d0464cdb591b550f6e610bf15085b18888

Fix: consumerd: user space metadata not regenerated

Observed Issue
==============

The LTTng-IVC tests fail on the `regenerate metadata` tests which
essentially:
  - Setups a user space session
  - Enables events
  - Traces an application
  - Stops tracing
  - Validates the trace
  - Truncates the metadata file (empties it)
  - Starts tracing
  - Regenerates the metadata
  - Stops the session
  - Validates the trace

The last trace validation step fails on an empty file (locally) or
a garbled file (remote).

The in-tree tests did no catch any of this since they essentially don't
test much. They verify that the command works (returns 0) but do not
validate any of its effects.

The issue was bisected down to:
  commit 6f9449c22eef59294cf1e1dc3610a5cbf14baec0 (HEAD)
  Author: Jérémie Galarneau <jeremie.galarneau@efficios.com>
  Date:   Sun May 10 18:00:26 2020 -0400

  consumerd: refactor: split read_subbuf into sub-operations
  [...]

Cause
=====

The commit that introduced the issue refactored the sub-buffer
consumption loop to eliminate code duplications between the user space
and kernel consumer daemons.

In doing so, it eleminated a metadata version check from the consumption
path.

The consumption of a metadata sub-buffer follows those relevant
high-level steps:
  - `get` the sub-buffer
    - /!\ user space specific /!\
      - if the `get` fails, attempt to flush the metadata cache's
        contents to the ring-buffer
  - populate `stream_subbuffer` properties (size, version, etc.)
  - check the sub-buffer's version against the last known metadata
    version (pre-consume step)
    - if they don't match, a metadata regeneration occurred: reset the
      metadata consumed position
  - consume (actual write/send)
  - `put` sub-buffer
  [...]

As shown above, the user space consumer must manage the flushing of the
metadata cache explicitly as opposed to the kernel domain for which the
tracer performs the flushing implicitly through the `get` operation.

When the user space consumer encounters a `get` failure, it checks
if all the metadata cache was flushed (consumed position != cache size),
and flushes any remaining contents.

However, the metadata version could have changed and yielded an
identical cache size: a regeneration without any new metadata will
yield the same cache size.

Since 6f9449c22, the metadata version check is only performed after
a successful `get`. This means that after a regeneration, `get`
never succeeds (there is seemingly nothing to consume), and the
metadata version check is never performed.

Therefore, the metadata stream is never put in the `reset` mode,
effectively not regenerating the data.

Note that producing new metadata (e.g. a newly registering app
announcing new events) would work around the problem here.

Solution
========

Add a metadata version check when failing to `get` a metadata
sub-buffer. This is done in `commit_one_metadata_packet()` when the
cache size is seen to be equal to the consumed position.

When this occurs, `consumer_stream_metadata_set_version()`, a new
consumer stream method, is invoked which sets the new metadata version,
sets the `reset` flag, and discards any previously bucketized metadata.

The metadata cache's consumed position is also reset, allowing the
cache flush to take place.

`metadata_stream_reset_cache()` is renamed to
`metadata_stream_reset_cache_consumed_position()` since its name is
misleading and since it is used as part of the fix.

Know drawbacks
==============

None.

Change-Id: I3b933c8293f409f860074bd49bebd8d1248b6341
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Reported-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

Fix: incorrect specifier %lu used with size_t argument

Fixes the following warning on 32-bit targets:

libtool: compile:  gcc -DHAVE_CONFIG_H -I../../../include -I../../../include -I../../../src -include config.h -I/build/include -I/home/jenkins/workspace/lttng-tools_master_portbuild/arch/armhf/babeltrace_version/stable-1.5/build/std/conf/std/liburcu_version/master/test_type/base/deps/build/include -Wall -Wno-incomplete-setjmp-declaration -Wdiscarded-qualifiers -Wmissing-declarations -Wmissing-prototypes -Wmissing-parameter-type -fno-strict-aliasing -pthread -g -O2 -MT consumer-stream.lo -MD -MP -MF .deps/consumer-stream.Tpo -c consumer-stream.c  -fPIC -DPIC -o .libs/consumer-stream.o
In file included from ../../../src/common/common.h:12:0,
                 from consumer.c:25:
consumer.c: In function ‘lttng_consumer_on_read_subbuffer_mmap’:
../../../src/common/error.h:161:35: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘size_t {aka unsigned int}’ [-Wformat=]
 #define DBG(fmt, args...) _ERRMSG("DEBUG1", PRINT_DBG, fmt, ## args)
                                   ^
../../../src/common/error.h:136:51: note: in definition of macro ‘__lttng_print’
    fprintf((type) == PRINT_MSG ? stdout : stderr, fmt, ## args); \
                                                   ^~~
../../../src/common/error.h:161:27: note: in expansion of macro ‘_ERRMSG’
 #define DBG(fmt, args...) _ERRMSG("DEBUG1", PRINT_DBG, fmt, ## args)
                           ^~~~~~~
consumer.c:1688:2: note: in expansion of macro ‘DBG’
  DBG("Consumer mmap write() ret %zd (len %lu)", ret, write_len);
  ^~~

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id9a571d8e94105428833baa053c6463b91484a03

Fix: consumerd: live client receives incomplete metadata

Observed issue
==============

Babeltrace 1.5.x and Babeltrace 2.x can both report errors (albeit
differently) when using the "lttng-live" protocol that imply that the
metadata they received is incomplete.

For instance, babeltrace 1.5.3 reports the following error:

```
[error] Error creating AST
[error] [Context] Cannot open_mmap_trace of format ctf.
[error] Error adding trace
[warning] [Context] Cannot open_trace of format lttng-live at path net://localhost:xxxx/host/session/live_session.
[warning] [Context] cannot open trace "net://localhost:xxxx/host/session/live_session" for reading.
[error] opening trace "net://localhost:xxxx/host/session/live_session" for reading.
[error] none of the specified trace paths could be opened.
```

While debugging both viewers, I noticed that both were attempting to
receive the available metadata before consuming the "data" streams'
content.

Typically, the following exchange between the relay daemon and the
lttng-live client occurs when the problem is observed:

bt lttng-live:
    emits LTTNG_VIEWER_GET_METADATA command
relayd:
    returns LTTNG_VIEWER_METADATA_OK, len = 4096 (default packet size)
bt lttng-live:
    consume 4096 bytes of metadata
    emits LTTNG_VIEWER_GET_METADATA command
relayd:
    returns LTTNG_VIEWER_NO_NEW_METADATA

When the lttng-live client receives the LTTNG_VIEWER_NO_NEW_METADATA
status code, it attempts to parse all the metadata it has received
since the last LTTNG_VIEWER_NO_NEW_METADATA reply. In effect, it is
expected that this forms a logical unit of metadata that is parseable
on its own.

If this is the first time metadata is received for that trace, the
metadata is expected to contain a trace declaration, packet header
declaration, etc.

If metadata was already received, it is expected that the newly parsed
declarations can be "appended" to the existing trace schema.

It appears that the relay daemon sends the
LTTNG_VIEWER_NO_NEW_METADATA while the metadata it has sent up to that
point is not parseable on its own.

The live protocol description does not require or imply that a viewer
should attempt to parse metadata packets until it hopefully succeeds
at some point. Anyhow:
  1) This would make it impossible for a live viewer to correctly
  handle a corrupted metadata stream beyond retrying forever,
  2) This behaviour is not implemented by the two reference
  implementations of the protocol.

Cause
=====

The relay daemon provides a guarantee that it will send any available
metadata before allowing a data stream packet to be served to the
client.

In other words, a client requesting a data packet will receive the
LTTNG_VIEWER_FLAG_NEW_METADATA status code (and no data) if it
attempts to get a data stream packet while the relay daemon has
metadata already available.

This guarantee is properly enforced as far as I can tell. However,
looking at the consumer daemon implementation, it appears that
metadata packets are sent as soon as they are available.

A metadata packet is not guaranteed to be parseable on its own. For
instance, it can end in the middle the an event declaration.

Hence, this hints at a race involving the tracer, the consumer daemon,
the relay daemon, and the lttng-live client.

Consider the following scenario:
  - Metadata packets (sub-buffers) are configured to be 4kB in size,
  - a large number of kernel events are enabled (e.g. --kernel --all),
  - the network connection between the consumer and relay daemons is
    slow

1) The kernel tracer will produce enough TSDL metadata to fill the
   first sub-buffer of the "metadata" ring-buffer and signal the
   consumer daemon that a buffer is ready. The tracer then starts
   writing the remaining data in the following available sub-buffers.

2) The consumer daemon metadata thread is woken up and consumes the
   first metadata sub-buffer and sends it to the relay daemon.

3) A live client establishes an lttng-live connection to the relay
   daemon and attempts to consume the available metadata. It receives
   the first packet and, since the relay daemon doesn't know about any
   follow-up metadata, receives LTTNG_VIEWER_NO_NEW_METADATA on the
   next attempt.

4) Having received LTTNG_VIEWER_NO_NEW_METADATA, the lttng-live client
   attempts to parse the metadata it has received and fails.

This scenario is easy to reproduce by inserting a "sleep(1)" at
src/bin/lttng-relayd/main.c:1978 (as of this revision). This simulates
a relay daemon that would be slow to receive/process metadata packets
from the consumer daemon.

This problem similarly applies to the user space tracer.

Solution
========

Having no knowledge of TSDL, the relay daemon can't "bundle" packets
of metadata until they form a "parseable unit" to send to the consumer
daemon.

To provide the parseability guarantee expected by the viewers, and by
the relay daemon implicitly, we need to ensure that the consumer
daemons only send "parseable units" of metadata to the relay daemon.

Unfortunately, the consumer daemons do not know how to parse TSDL
either. In fact, only the metadata producers are able to provide the
boundaries of the "parseable units" of metadata.

The general idea of the fix is to accumulate metadata up to a point
where a "parseable unit" boundary has been identified and send that
content in one request to the relay daemon. Note that the solution
described here only concerns the live mode. In other cases, the
mechanisms described are simply bypassed.

A "metadata bucket" is added to lttng_consumer_stream when it is
created from a live channel. This bucket is filled until the
consumption position reaches the "parseable unit" end position.

A refresher about the handling of metadata in live mode
-------------------------------------------------------

Three "events" are of interest here and can cause metadata to be
consumed more or less indirectly:
  1) A metadata packet is closed, causing the metadata thread to wake
     up
  2) The live timer expires
  3) A data sub-buffer is closed, causing the data thread to wake-up

1) The first case is simple and happens regardless of whether or not
   the tracing session is in live mode or not. Metadata is always
   consumed by the metadata thread in the same way. However, this
   scenario can be "caused" by (2) and (3). See [1]. A sub-buffer is
   "acquired" from the metadata ring-buffer and sent to the relayd
   daemon as the payload of a "RELAYD_SEND_METADATA" command.

2) When the live timer expires [2], the 'check_stream' function is
   called on all data streams of the session. As its name clearly
   implies, this function is responsible for flushing all streams or
   sending a "live beacon" (called an "empty index" in the code) if
   there is no data to flush. Any flushed data will result in (3).

3) When a data sub-buffer is ready to be consumed, [1] is invoked
   by the data thread. This function acquires a sub-buffer and sends
   it to the relay daemon through the data connection.

   Then, an important synchronization step takes place. The index of
   the newly-sent packet will be sent through the control
   connection. The relay daemon waits for both the data packet and its
   matching index before making the new packet visible to live
   viewers.

   Since a data packet could contain data that requires "newer"
   metadata to be decoded, the data thread flushes the metadata stream
   and enters a "waiting" phase to pause until all metadata present in
   the metadata ring buffer has been consumed [3].

   At the end of this waiting phase, the data thread sends the data
   packet's index to the relay daemon, allowing the relayd to make it
   visible to its live clients.

How to identify a "parseable unit" boundary?
--------------------------------------------

In the case of the kernel domain, the kernel tracer produces the
actual TSDL descriptions directly. The TSDL metadata is serialized to
a metadata cache and is flushed "just in time" to the metadata
ring-buffer when a "get next" operation is performed.

There is no way, from user space, to query whether or not the metadata
cache of the kernel tracer is empty. Hence, a new
RING_RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK command was added to
query whether or not the kernel tracer's metadata cache is empty when
acquiring a sub-buffer.

This allows the consumer daemon to identify a "coherent" position in
the metadata stream that is safe to use as a "parseable unit"
boundary.

As for the user space domain, since the session daemon is responsible
for generating the TSDL representation of the metadata, there is no
need to change LTTng-ust APIs.

The session daemon generates coherent units of metadata and adds them
to its "registry" at once (protected by the registry's lock). It then
flushes the contents to the consumer daemon and waits for that data to
be consumed before proceeding further.

On the consumer daemon side, the metadata cache is filled with the
newly-produced contents. This is done atomically with respect to
accesses to the metadata cache as all accesses happen through a
dedicated metadata cache lock.

When the consumer's metadata polling thread is woken-up, it will
attempt to acquire (`get_next`) a sub-buffer from the metadata stream
ring-buffer. If it fails, it will flush a sub-buffer's worth of
metadata to the ring-buffer and attempt to acquire a sub-buffer again.

At this point, it is possible to determine if that sub-buffer is the
last one of a parseable metadata unit: the cache must be empty and the
ring-buffer must be empty following the consumption of this
sub-buffer. When those conditions are met, the resulting metadata
`stream_subbuffer` is tagged as being `coherent`.

Metadata bucket
---------------

A helper interface, metadata_bucket, is introduced as part of this
fix. A metadata_bucket is `fill`ed with `stream_subbuffer`s, and is
eventually `flushed` when it is filled by a `coherent` sub-buffer.

As older versions of LTTng-modules must remain supported, this new
helper is not used when the
RING_RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK operation is not
available. When the operation is available, the metadata stream's
bucketization is enabled, causing a bucket to be created and the
`consume` callback to be swapped.

The `consume` callback of the metadata streams is replaced by a new
implementation when the metadata bucketization is activated on the
stream. This implementation returns the padded size of the consumed
sub-buffer when they could be added to the bucket. When the bucket is
flushed, the regular `mmap`-based consumption function is called with
the bucket's contents.

Known drawbacks
===============

This implementation causes the consumer daemon to buffer the whole
initial unit of metadata before sending it. In practice, this is not
expected to be a problem since the largest metadata files we have seen
in real use are a couple of megabytes wide.

Beyond the (temporary) memory use, this causes the metadata thread to
block while this potentially large chunk of metadata is sent (rather
than blocking while sending 4kb at a time).

The second point is just a consequence of existing shortcomings of the
consumerd; slow IO should not affect other unrelated streams. The
fundamental problem is that blocking IO is used and we should switch
to non-blocking communication if this is a problem (as is done in the
relay daemon).

The first point is more problematic given the existing tracer APIs.
If the tracer could provide the boundary of a "parseable unit" of
metadata, we could send the header of the RELAYD_SEND_METADATA command
with that size and send the various metadata packets as they are made
available. This would make no difference to the relay daemon as it is
not blocking on that socket and will not make the metadata size change
visible to the "live server" until it has all been received.

This size can't be determined right now since it could exceed the
total size of the "metadata" ring buffer. In other words, we can't wait
for the production of metadata to complete before starting to consume.

Finally, while implementing this fix, I also realized that the
computation of the rotation position of the metadata streams is
erroneous. The rotation code makes use of the ring-buffer's positions
to determine the rotation position. However, since both user space and
kernel domains make use of a "cache" behind the ring-buffer, that
cached content must be taken into account when computing the metadata
stream's rotation position.

References
==========

[1] https://github.com/lttng/lttng-tools/blob/d5ccf8fe0/src/common/consumer/consumer.c#L3433
[2] https://github.com/lttng/lttng-tools/blob/d5ccf8fe0/src/common/consumer/consumer-timer.c#L312
[3] https://github.com/lttng/lttng-tools/blob/d5ccf8fe0/src/common/consumer/consumer-stream.c#L492

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I40ee07e5c344c72d9aae2b9b15dc36c00b21e5fa

consumerd: refactor: split read_subbuf into sub-operations

The read_subbuf code paths intertwine domain-specific operations and
metadata/data-specific logic which makes modifications error prone and
introduces a fair amount of code duplication.

lttng_consumer_read_subbuffer is effectively turned into a template
method invoking overridable callbacks making most of the consumption
logic domain and data/metadata agnostic.

The goal is not to extensively clean-up that code path. A follow-up
fix introduces metadata buffering logic which would not reasonably fit
in the current scheme. This clean-up makes it easier to safely
introduce those changes.

No changes in behaviour are intended by this change.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I9366f2e2a38018ca9b617b93ad9259340180c55d

Backport LTTNG_OPTIONAL util

A follow-up fix makes use of the LTTNG_OPTIONAL utility.

optional.h is identical to the version found in 3e778ab02.

Change-Id: I98a3efefe1ab6193e0d3c9c16d00f797551f36d9
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

sessiond: enforce mmap output type for kernel metadata channel

A follow-up fix causes the consumer daemon to accumulate metadata
packets into a complete "unit" that can be parsed before sending it to
the relay daemon.

The consumer daemon will also need to extract the contents of the
metadata cache when computing a rotation position (follow-up fix too).

Hence, it is not possible to rely on the splice back-end as the
consumer daemon may need to accumulate more content than can be backed
by the ring buffer's underlying pages.

In both cases, the splice output mode could still be used when
combined with a memfd, but I see no tangible benefit. Moreover, it
would require a 3.17 kernel.

Curiously the kernel metadata channel configuration appears to be
hard-coded twice; once in the ltt_kernel_session's
ltt_kernel_metadata, and once again in
kernel_consumer_add_metadata(). kernel_consumer_add_metadata is
modified to use the kernel session's metadata configuration.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ia4cad82f595d3eee50d081851c234d4c2ef7ee5f

consumerd: tag metadata channel as being part of a live session

metadata channels that are part of a live session must be handled
differently than when they are part of non-live sessions since
complete "metadata units" must be accumulated before they are
forwarded to a relay daemon.

This allows a follow-up fix to use this information since the
live_timer_interval of a metadata channel is always 0.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I53db4bc717b149ed20e0309531db6f0241e873e1

consumerd: pass channel instance to stream creation function

Both callsites of consumer_allocate_stream() set the stream's "chan"
pointer after the creation. Pass the channel directly to the stream
creation function so it can initialize the stream according to the
channel's settings.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Icea7088e7695e310585bf398e14e6443d67a30bb

consumerd: cleanup: use buffer view interface for mmap read subbuf

Replace explicit pointer + size parameters by an lttng_buffer_view
in lttng_consumer_on_read_subbuffer_mmap().

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I76f35b3e295c596cdf4bbb8a6d01168a850a721a

consumerd: move address computation from on_read_subbuffer_mmap

The computation of the subbuffer's address is moved outside of
lttng_consumer_on_read_subbuffer_mmap to make it usable with a regular
buffer. This facilitates an upcoming change.

Moreover this has the benefit of isolating domain-specific logic from
this function which is supposed to be domain-agnostic.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I16f8ccaa73804f98fa03e69136548e6d6b7782e5

Add lttng_dynamic_buffer_append_view util

Add lttng_dynamic_buffer_append_view() which appends the contents
of a buffer view to a dynamic buffer.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I4082ba2c848b79aa2116847987067453638de441

Add a util to create a buffer view from a raw buffer

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

consumerd: refactor: combine duplicated check_*_functions

The check_ust_stream and check_kernel_stream functions are identical
except for the call to the domain-specific call to
consumer_flush_*_index.

A "flush_index" callback is passed to check_stream in order to share
the rest of that code.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Iafdb64192322c0106a555b67f54290dadc4f0579

kerner-ctl: add RING_RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK

Add a wrapper for RING_RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK
which gets the next metadata subbuffer and returns a boolean flag
indicating whether the metadata is guaranteed to be in a consistent
state at the end of this sub-buffer (can be parsed).

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I13fbdfe51c3c4ef04581409e0fbc9837ed6d555d

Fix: check validity of a stream before invoking ust flush command

[
  BACKPORT INFO: already present in stable 2.9 but not in rev7
  https://github.com/lttng/lttng-tools/commit/610959b3677f92eb93e013ee87af49df816c2f48
]

At the time ustctl_flush_buffer is called the ustream object might have
already been freed on lttng-ust side.

This can happen following a lttng_consumer_cleanup_relayd and concurrent
consumer flush command (lttng stop).

The train of events goes as follows.

An error on communication with lttng-relayd occurs.
lttng_consumer_cleanup_relayd flags the streams for deletion
(CONSUMER_ENDPOINT_INACTIVE). validate_endpoint_status_data_stream calls
consumer_del_stream.

At the same time the hash table of streams is iterated over in the
flush_channel function following a stop command. The loop is iterating on
a given stream. The current thread is unscheduled before taking the stream
lock.

In the initial thread, the same stream is the current iteration of
cds_lfht_for_each_entry in validate_endpoint_status_data_stream.

consumer_del_stream is called on it. The stream lock is acquired, and
destroy_close_stream is called. lttng_ustconsumer_del_stream is eventually
called and at this point the ustream is freed.

Going back to the iteration in flush_channel. The current stream is still
valid from the point of view of the iteration, ustctl_flush_buffer is then
called on a freed ustream object.

This can lead to unknown behaviour since there is no validation on
lttng-ust side. The underlying memory of the ustream object is garbage at
this point.

To prevent such scenario, we check for the presence of the node in the
hash table via cds_lfht_is_node_deleted. This is valid because the node is
removed from the hash table before deleting the ustream object on
lttng-ust side. The removal from the hash table also requires the stream
lock ensuring the validity of cds_lfht_is_node_deleted return value.

This duplicate similar "validation" check of the stream object. [1][2]

[1] src/common/consumer/consumer.c:consumer_close_channel_streams
[2] src/common/ust-consumer/ust-consumer.c:close_metadata

This issue can be reproduced by the following scenario:

    Modify flush_channel to sleep (i.e 10s) before acquiring the lock on
    a stream.

    Modify lttng-ust ustctl_destroy_stream to set the
    ring_buffer_clock_read callback to NULL.
      Note: An assert on !cds_lfht_is_node_deleted in flush channel
      after acquiring the lock can provide the same information. We are
      modifying the callback to simulate the original backtrace from our
      customer.

    lttng-relayd
    lttng-sessiond
    lttng create --live
    lttng enable-event -u -a
    lttng start
    Start some applications to generate data.
    lttng stop
      The stop command force a flush of the channel/streams.
    pkill -9 lttng-relayd
    Expect assert or segfault

The original customer backtrace:

  0  lib_ring_buffer_try_switch_slow (handle=<optimized out>, tsc=<synthetic pointer>, offsets=0x3fffa9b76c80, chan=0x3fff98006e90, buf=<optimized out>,
     mode=<optimized out>) at /usr/src/debug/lttng-ust/2.9.1/git/libringbuffer/ring_buffer_frontend.c:1834
  1  lib_ring_buffer_switch_slow (buf=0x3fff98016b40, mode=<optimized out>, handle=0x3fff98017670)
     at /usr/src/debug/lttng-ust/2.9.1/git/libringbuffer/ring_buffer_frontend.c:1952
  2  0x00003fffac680940 in ustctl_flush_buffer (stream=<optimized out>, producer_active=<optimized out>)
     at /usr/src/debug/lttng-ust/2.9.1/git/liblttng-ust-ctl/ustctl.c:1568
  3  0x0000000010031bc8 in flush_channel (chan_key=<optimized out>) at ust-consumer.c:772
  4  lttng_ustconsumer_recv_cmd (ctx=<optimized out>, sock=<optimized out>, consumer_sockpoll=<optimized out>) at ust-consumer.c:1651
  5  0x000000001000de50 in lttng_consumer_recv_cmd (ctx=<optimized out>, sock=<optimized out>, consumer_sockpoll=<optimized out>) at consumer.c:2011
  6  0x0000000010014208 in consumer_thread_sessiond_poll (data=0x10079430) at consumer.c:3192
  7  0x00003fffac608b30 in start_thread (arg=0x3fffa9b7bdb0) at pthread_create.c:462
  8  0x00003fffac530d0c in .__clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:96

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I5ad8c2d0c37675d3d0fc4b4669db7c221bef78e3

BACKPORT: Tests: fix: test_relayd_working_directory fails as user

A formating issue introduced by 15da468cd causes the temporary
directory of the a test to be initialized incorrectly, causing it to
fail when it is not skipped (executed as a non-root user).

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Idd09f27fa2ce0f5991056ab52bc1718080122151

BACKPORT: Tests: fix: test_relayd_working_directory fails as root

From the original bug report:

This test succeeds as user, but fails as root:
not ok 23 - Warning about missing write permission is present

    Failed test 'Warning about missing write permission is present'
    in tools/working-directory/test_relayd_working_directory:test_relayd_debug_permission() at line 182.

The warning does not trigger because root always has access.

Skip this test since the permission check will succeed and the relay
daemon won't produce the expected error message.

Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I4eb29958aaca78405e1fdd2392d73472af0d5912

BACKPORT: Tests: fix: tmp dir can be a symlink

Get the real path to perform valid comparison.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I1b5a5ccb6787681a5dc84bdb1708811008c9c525

BACKPORT FIX: update test file against upstream

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I8fa36d6bd4cbf1196bdf031360f118a8c3aa3cc0

BACKPORT FIX: wrong file name

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I268d34671679b9c38b3571406d9da0a4766ed615

EfficiOS backport 2.9 revision 7

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

Fix: max_t/min_t macros are missing cast on input

The semantic expected from max_t and min_t is to perform the max/min
comparison in the type provided as first parameter.

Cast the input parameters to the proper type before comparing them,
rather than after. There is no more need to cast the result of the
expression now that both inputs are cast to the right type.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: Connect timeout arithmetic in inet/inet6 (v4)

The nanoseconds part of the timespec struct time_a is not always
bigger than time_b since it wraps around each second.

Use 64-bit arithmetic to compute the difference.

Merge/move duplicated code into utils.c.

This function is really doing two things. Split it into
timespec_to_ms() and timespec_abs_diff().

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Bound maximum data read to RECV_DATA_BUFFER_SIZE per iteration

Do not consume everything all at once even if there is data left on the
socket. This is to provide fairness to the overall data handling of all
connections.

It also provide a bounded processing execution for a data processing
iteration.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

relayd: do not prioritize control events over data.

Simplify the algorithm used by relayd for control and data connections
handling.

Use the notion of activity phase. An activity phase represent a phase
for which all connections with activity (poll/epoll) are not yet processed.

When an active connection is processed, her activity phase is set to the
current activity phase to prevent further progress during the same
activity phase.

Once all active connections (poll events) have been processed during
the current activity phase, the current activity phase is incremented.

This give fairness across all connections during a given activity phase.

This can also serve as a base for future work toward resources based
prioritizing.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

Remove unnecessary mutex unlock

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

Explicit data pending reason consumer side

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

Cleanup: missing line in consumer-stream.c

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

consumer: Rename net_seq_idx to relayd_id

The consumer's streams refer to a 'net_seq_idx' of which the
meaning must have been lost in the sands of time. It is a
unique identifier of a given relay daemon. Hence, renaming it to
'relayd_id' appears sensible.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

Cleanup: remove dead assignment

Both calling sites do not use the return value and errors are already
managed inside the called function.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

EfficiOS backport 2.9 revision 6

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

Teardown relayd on communication error during data pending

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

Set consumer's verbosity to the max level on --verbose-consumer

The consumer's verbosity is set to '1' when --verbose-consumer
is used when launching the session daemon. This means that all
DBG2/3() statements are ignored.

This commit always sets the consumer's verbosity to the maximal
level.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Perform local data pending check then relayd

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

fd-tracker Fix: do not warn on index file not found

Upstream status pending on fd-tracker merge

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

fd-tracker Fix: error path lead to null pointer dereference of handle

Upstream status: pending review and upstream merge of the fd-tracker
feature.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

Fix: double put on error path

Let relay_index_try_flush be responsible for the self-reference put on
error path.

Code flow of relay_index_try_flush is a bit tricky but the only error
flow (via relay_index_file_write) will always mark the index as flushed
and perform the self-reference put.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: holding the stream lock does not equate to having data pending

The live timer can hold the stream lock while sending empty beacon. An
empty beacon does not mean that data is still pending for the stream.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: skip uid registry when metadata key is 0

A value of zero for the metadata key indicate that metadata was never
created/pushed to the consumer.

This can occur in scenario were a tracker is present since metadata
might never be created/pushed.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: acquire stream lock during kernel metadata snapshot

The stream lock is not taken when interacting with the kernel
metadata stream that is created at the time a snapshot is taken.

This was noticed while reviewing the code for an unrelated reason,
so there is no known problem caused by this. Nevertheless, this
is incorrect as the stream is globally visible in the consumer.

Moreover, the stream was not cleaned-up which can cause a leak
whenever a metadata snapshot fails.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>

Fix: skip closed session on viewer listing

There is  no value in listing  a closed session. A  viewer cannot hook
itself to a closed session in live mode and the session is about to be
removed from the sessions hash table.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: use LTTNG_VIEWER_ATTACH_UNK to report a closed session

LTTNG_VIEWER_NEW_STREAMS_HUP is not a valid error number for the
LTTNG_VIEWER_ATTACH_SESSION command. This result in erroneous error
reporting on the client side.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: perform relayd socket pair cleanup on control socket error

A reference to the local context for the socket pair is used to "force" an
evaluation of the data and metadata streams since we changed the endpoint
status. This imitates what is currently done for the data socket.

This prevents hitting network timeouts multiple times in a row when an
error occurs. For now, there is no mechanism for retry hence
"terminating" all communication make sense and prevent unwanted delays
on operation.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: relayd control socket mutex is not destroyed

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Rev5: Update extra_version information

Fix: remove inode from inode registry ht

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: unbalanced fd references

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

relayd: unlink stream files through the fd-tracker

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: crash on close of partially initialized handle

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

relayd: unlink index files through the fd-tracker

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: rlim_cur and rlim_max printing causes a warning on some archs

rlim_cur and rlim_max were assumed to be unsigned longs, but they
are explicitly 64-bits long on 32 bits archs (warning seen for
powerpc 32 and arm 32 builds).

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Tests: add fd-tracker tests for the unlink operation

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fd-tracker test: register rcu thread of test application

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fd-tracker: use lttng_inode to store fs_handle's path

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fd-tracker: remove duplicate clear of O_CREAT flag

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fd-tracker build fix: missing parameter in poll compat function signature

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fd-tracker: perform unsuspendable_fd release through call_rcu

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fd-tracker: add the lttng-inode interface

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fd-tracker: add the unlink operation to fs handles

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fd-tracker: remove unneeded header inclusion

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fd-tracker: add an optimization note to the fd-tracker

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: lttng-track(1), lttng-untrack(1): document new properties/options

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Backport: trackers: bump MI version to 4.0

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

Backport: trackers: commands: validate duplicate options

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

Backport: Fix: tracker: no command shortcut for new trackers

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

Backport: trackers: add sessiond tracker list implementation

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

Backport: Fix: tracker: list/track/untrack commands leak strings

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

Backport: Fix: tracker: ensure consistency of tracker states

On error when adding/removing from either UST or kernel trackers,
we need to roll back the state of our internal lists.

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

Backport: trackers: tests: adapt tests to new xsd schemas

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

Backport: trackers: update MI to new xsd schema

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

Backport: trackers: update config xsd schema

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

Backport: trackers: update lttng-sessiond

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

Backport: trackers: update list/track/untrack commands

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

Backport: trackers: update liblttng-ctl

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

Backport: trackers: update sessiond communication protocol

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

Backport: trackers: update lttng-modules tracer ABI

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

Backport: trackers: change error code from "pid" to "id"

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

Backport: LTTNG-RELAYD(8): document the --fd-pool-size option

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: relayd: rename fd-cap parameter to fd-pool-size

Rename the fd-cap parameter and change its default behaviour.
The minimum number of file descriptor is raised to 100 and a
"reserve" amount of 10 fds is allowed to accomodate transient
fd uses that can't be tracked by the relay daemon.

The --fd-pool-size will accept parameters in the
[100, fileno soft limit] interval.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: fd-tracker: log tracker capacity on creation

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: relayd: replace lttng_index_file with relay_index_file

lttng_index_file is shared between the consumer and relay daemon.
However, the introduction of the fd-tracker in the relay daemon
makes it hard to cleanly share this piece of code between both
daemons.

The ctf-index.h header is still shared by both daemons which
is the most important part. The lttng/relay_index_file class
is a fairly thin wrapper around file system operations (unlink,
read, and write an index) so there is little value gained in
sharing the code vs heavily modifying it to handle the presence
of an fd-tracker in the process.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: Move index initialization to ctf-index.h

This initialization code is moved to a common header to re-use
it in a follow-up patch.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: Fix: fully initialize viewer stream before publishing it

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: relayd: use the fd-tracker to track stream_fd fds

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: relayd: track the live client connections socket

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: relayd: track relayd control connection sockets

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: relayd: track relayd data connection sockets

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: relayd: track the data listener socket

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: relayd: track the control listener socket

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Backport: relayd: track the live listener socket

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>