Fix: add consumer wake up pipe to avoid race

UST application will notify the wait_fd pipe for every subbuffer that it
writes and ready to be consumed. However, on *high* load systems, this
1:1 property can fail if the pipe gets filled up. For performance
reason, UST will ignore this error and continue since it can't wait for
the pipe to clear up.

This triggers a race condition where we have *one* wake up on the UST
pipe for potentially multiple subbuffers. A data pending command will
wait forever on streams that still has data but the data thread could'nt
consumed them because of this 1:n possible race. Using the stop command
without waiting would mean a memory/fd leak of the stream.

Thus, we add a consumer wake up pipe here that notifies the data thread
if there is still data to be read after a successful read subbuffer
call. With this, we end up handling the residual buffers if any since
the data thread is always notified when there is still data to be read.

Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: take session list lock when listing tp

This is important since the list tracepoints command access the
application socket to ask the application for its TPs. The session list
lock protects the ordering of message for those sockets.

This was triggering out of order message between the session daemon and
an application thus triggering undefined behavior.

Fixes #774

Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: don't print stream name in error message

The stream received, in per UID, is actually a temporary stream object
that only contains the UST object data which is the relevant part for
UST to use.

Thus on error the name was random data thus print the valid handle
descriptor instead of invalid data.

Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: use after free of a relayd stream

A race could occur with a stream destruction and a control connection
being destroyed emptying its recv_list. A freed stream could still be in
the list thus having a use after free during the connection destroy.

That was triggering undefined behavior from infinite looping to
segmentation faults.

We've observed this issue on high load stress test. A relayd received
all the stream but NOT the streams sent command which empty the list.
This can happen if a start tracing never occured or failed on the
application side thus the close stream command is sent to the relayd
freeing the stream before it is removed from that list.

Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: don't quiet the consumer if opt_quiet is not set

Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: misc spelling errors

Signed-off-by: Michael Jeanson <mjeanson@ubuntu.com>
Fix: don't delete stream from connection recv list

We don't need to delete them from the list during a connection destroy
because it's only a reference to the stream that might be valid or not
during the connection destroy. There is no need at all to access the
stream's pointer at that point.

Commit cd2ef1ef1d54ced9e4d0d03b865bb7fc6a905f80 did not fixed the full
issue so this should fix the use after free race for good.

Signed-off-by: David Goulet <dgoulet@efficios.com>
Update ChangeLog with 2.4.1 release

Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: fail setup metadata cmd must destroy it

If the setup metadata command failed, ask the consumer to destroy the
channel or else it will stay in limbo in the consumer thus FD and memory
leaking.

Signed-off-by: David Goulet <dgoulet@efficios.com>