Conditional compilation introduced by lttng-modules commit

  0007344741ef65259bc52dea72259173dfbf96c0

needs to be applied for kernels 3.12.30 and up in the 3.12.x branch.

Signed-off-by: David Engraf <david.engraf@sysgo.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Version 2.4.3

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

Fix: compaction instrumentation update for 3.14.x stable kernels

Conditional compilation introduced by lttng-modules commit

  0007344741ef65259bc52dea72259173dfbf96c0

needs to be applied to kernels 3.14.25 and up in the 3.14.x branch.

Squashed with commit 0007344741ef65259bc52dea72259173dfbf96c0 which was
originally targetting 3.16.

Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reported-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: context alignment not properly handled

This issue affects only architectures without efficient unaligned
accesses, only when a context field with larger alignment follows a
context field with smaller alignment. It generates unreadable traces
when such context fields are enabled in this configuration.

Fixes #858

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

Check for stale version.h files

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

Fix: lttng-modules teardown NULL pointer OOPS

Accessing the lttng channel and lttng session from the metadata ring
buffer client is a bad idea, because we don't have any reference
ensuring those are valid for the lifetime of the metadata cache.
Therefore, rather than keeping a lttng channel as private data pointer
for the metadata ring buffer channel, keep a pointer to the metadata
cache instead: this will ensure we don't shoot ourself in the foot and
access data we for which coherency is not guaranteed (we don't hold any
reference to it).

Anyway, the only reason why we needed to access the lttng session from
the metadata client in the first place was the UUID of the session. Copy
it into the metadata cache instead.

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

Fix: handle concurrent flush vs get_next_subbuf on metadata cache

The "flush" operation can be performed on the metadata file descriptor
concurrently with get_next_subbuffer operations by different processes
(e.g. lttng session daemon issuing flush at "stop" concurrently with
consumer daemon issuing get_next_subbuf for metadata I/O). We need
to protect the metadata cache from those concurrent use by introducing a
mutex.

This fixes a race where metadata from a kernel trace is corrupted due to
this scenario. The corruption shows up like the same metadata content (a
metadata packet) being written twice consecutively in the metadata
stream, thus triggering a babeltrace "parse error" when trying to read
the trace.

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

Version 2.4.2

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

Fix: statedump handle oom case, handle errors

lttng_enumerate_file_descriptors should check the pointer returned by
__get_free_page() (check if NULL).

do_lttng_statedump should check the sub-function return values. For
lttng_enumerate_block_devices(), we allow -ENOSYS to continue (if not
implemented).

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

Fix: correct typo in kernel version number

A typo in a preprocessor conditional verifying the range in which the
current kernel version is situated caused build failure for modules on
3.5.0 specifically, by trying to use the new api for block_rq_complete
which has not been backported from the 3.15 branch to the 3.5 branch.

Signed-off-by: Antoine Busque <antoine.busque@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: blktrace instrumentation for backported branches

The following commit from kernel 3.15 changing the API of a block layer
tracepoint has been backported to multiple branches:

commit af5040da01ef980670b3741b3e10733ee3e33566
Author: Roman Pen <r.peniaev@gmail.com>
Date:   Tue Mar 4 23:13:10 2014 +0900

    blktrace: fix accounting of partially completed requests

This patch fixes the resulting build failure by adding the proper
version checks. The versions and corresponding commit SHA-1 hashes are
as follow:

   3.2.58
       commit 5b85afa68e4f56c27f1d5c6f49e5257bce6448e6

   3.4.91
       commit 14eee5bd065d6aac0acbdc6092a25ba68c55b9c8

   3.10.41
       commit e9d933941569c107e0083c3c115467c699a57db2

   3.12.21
       commit 5104b40a981d26212ced149fbd43ad0b6b72910b

   3.14.15
       commit 0a8eda9c00ef37e8b40de77f2b0714317191bcf2

Signed-off-by: Antoine Busque <antoine.busque@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: refuse overwrite mode buffers with less than two subbuffers

Fixes #793

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

Fix: lttng modules system call generation script

Fixes #771

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

Fix: incorrect rwbs field type in block_bio_queue

Within lttng-modules instrumentation starting from kernel 3.9.0, the
block_bio_queue instrumentation has incorrect rwbs field type, and does
not print "comm" as an array of text.

The result is that we are writing values to what we believe to be an
"unsigned int", which is actually described as an array of RWBS_LEN byte
(8 bytes). This discrepancy between type description and the actual
tp_assign() incrementing the write offset leads to what appears as
corruption of the following "comm" field in the trace viewer output: the
viewer will skip the first bytes of the "comm" field, erroneously
thinking they belong the the previous "rwbs" field.

Fixes #794

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

Fix: blktrace instrumentation for v3.2.58+ stable branch

Starting with Linux kernel v3.2.58 within the v3.2 Linux stable branch:

commit 5b85afa68e4f56c27f1d5c6f49e5257bce6448e6
Author: Roman Pen <r.peniaev@gmail.com>
Date:   Tue Mar 4 23:13:10 2014 +0900

    blktrace: fix accounting of partially completed requests

    commit af5040da01ef980670b3741b3e10733ee3e33566 upstream.

The module API for a block layer tracepoint changes. Fix the associated
build failure.

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

Fix: update block instrumentation to 3.15 kernel

Required with lttng-modules stable-2.4 branch because this fix is
backported to stable kernels too.

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

Fix: pass proper args when writing commit counter

lib_ring_buffer_write_commit_counter()'s 'buf_offset' argument should
contain offset of beginning of area used by the record being comitted.

However, lib_ring_buffer_commit() passes ctx->buf_offset, that gets
advanced by lib_ring_buffer_write() and thus points to just-after-
end-of-record at lib_ring_buffer_commit() time. This causes
lib_ring_buffer_write_commit_counter() to return without changing
commit_hot[idx].seq, due to

if (unlikely(subbuf_offset(offset - commit_count, chan)))
return;

Since after-crash data extraction tool checks 'seq' field to find out
how much data is in buffer, this results into inavailability of
data from partially-filled subbuffer for after-crash analysis.

This patch modifies lib_ring_buffer_write_commit_counter() and all its
callers to pass and expect the end of the area. So code works as it
should, and complete information becomes visible in crash dump.

[ Changelog inspired from Nikita Yushchenko's original patch. ]

Fixes #784

Reported-by: Nikita Yushchenko <nyoushchenko@mvista.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: allow racy tracepoint string input from kernel and userspace

Fixes #781

Acked-by: David Goulet <dgoulet@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Version 2.4.1

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

Fix: rcu instrumentation: add const qualifier to char pointers

Follow this 3.12 instrumentation update in mainline Linux:

commit e66c33d579ea566d10e8c8695a7168aae3e02992
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Fri Jul 12 16:50:28 2013 -0400

    rcu: Add const annotation to char * for RCU tracepoints and functions

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

Fix: add missing module version information

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

Fix: block instrumentation: < 3.14 don't have bi_iter

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

Fix: update btrfs instrumentation to kernel 3.14

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

Fix: update block layer instrumentation to kernel 3.14

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

Fix file permissions for lttng-statedump-impl.c

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

Version 2.4.0

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

Fix: load state dump even if work-around lookup fails

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

Cleanup: fix comment

Fixes #652

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

Fix: correctly version kvm events to build against v3.0 kernel

Cleanly build against v3.0 kernel.  I didn't add versioning for mainline commit 0d460ffc as it's build compatible.

Signed-off-by: Tony Jones <tonyj@suse.de>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Add extraversion (e.g. -rc4) to lttng-tracer modinfo

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

Version 2.4.0-rc4

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

Fix: use after free in ring buffer clients

Don't use ring buffer client's struct lttng_channel from ioctl which
applies to ring buffer streams, because lttng_channel is freed while lib
ring buffer stream and channel are still in use. Their lifetime persists
until the consumer daemon releases its handles on the related stream
file descriptors.

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

Fix: Add statedump exit so module is not permanent

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

Cleanup: move callback init to static initialization

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

Fix: OOT lttng-statedump tracepoints not visible with signed kernels

Users have reported being unable to trace non-signed modules loaded
within a kernel supporting module signature.

Here is the relevant report of this issue to Linux upstream, with a
proposed fix: https://lkml.org/lkml/2014/2/10/747

Work-around the issue for lttng-statedump.ko tracepoints.

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

Version 2.4.0-rc3

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

Fix: tracepoint event name mapping at unregister

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

Fix: tracepoint name remapping

Commit

  "Introduce API to remap event names exposed by LTTng"

failed to map the event names enabled by the user to tracepoint names
known to the kernel. For instance, tracing with the kmem_kmalloc event
enabled is not gathering any event. This issue applies to all tracepoint
events declared with a different name within LTTng than within the Linux
kernel.

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

Fix: enable event error path memory corruption

The call to

  kmem_cache_free(event_cache, event);

after setting event to ERR_PTR() value is causing memory corruption
(kernel oops). This bug has been introduced very recently by commit:

  Fix: provide more precise error report for enable event

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

Update kvm instrumentation to Linux 3.13

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

Update sched instrumentation to Linux 3.13

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

Fix: provide more precise error report for enable event

Fixes #658

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

Fix: quote event name in metadata

Allows adding events with a "-" within the name with --probe or
--function.

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

Add version info to lttng-tracer.ko modinfo

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

Version 2.4.0-rc2

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

Fix: client_packet_header() uses wrong packet

It should use lib_ring_buffer_read_offset_address() to get the packet
being read, rather than lib_ring_buffer_offset_address(), which is only
meant to be used when writing to the packet.

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

Cleanup: fix typo in ring buffer backend comment

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

Fix: handle unknown event type parameter

Skip to an error path if the event type is unknown.

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

Fix: eliminate timestamp overlap between packets

By using the timestamp sampled at space reservation when the packet is
being filled as "end timestamp" for a packet, we can ensure there is no
overlap between packet timestamp ranges, so that packet timestamp end <=
following packets timestamp begin.

Overlap between consecutive packets becomes an issue when the end
timestamp of a packet is greater than the end timestamp of a following
packet, IOW a packet completely contains the timestamp range of a
following packet.  This kind of situation does not allow trace viewers
to do binary search within the packet timestamps. This kind of situation
will typically never occur if packets are significantly larger than
event size, but this fix ensures it can never even theoretically happen.

The only case where packets can still theoretically overlap is if they
have equal begin and end timestamps, which is valid.

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

gcc blacklist: only apply when building with gcc

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

Blacklist ARM gcc 4.8.0, 4.8.1, 4.8.2

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

Version 2.4.0-rc1

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

Update ext4 instrumentation to Linux 3.12

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

Update RCU instrumentation to Linux 3.12

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

Update btrfs instrumentation to 3.12 kernel

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

Update vmscan instrumentation to Linux 3.12

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

update: kmem instrumentation 3.12 kernel support

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

lttng-statedump-impl: Use generic hard irqs for Linux >= 3.12

Quoting the original patch changelog from Otavio Salvador:

> The Linux kernel 3.12 uses the generic hard irqs system for all
> architectures and dropped the GENERIC_HARDIRQ option, as can be seen
> at the commit quoted below:
>
> ,----
> | commit 0244ad004a54e39308d495fee0a2e637f8b5c317
> | Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
> | Date:   Fri Aug 30 09:39:53 2013 +0200
> |
> |     Remove GENERIC_HARDIRQ config option
> |
> |     After the last architecture switched to generic hard irqs the config
> |     options HAVE_GENERIC_HARDIRQS & GENERIC_HARDIRQS and the related code
> |     for !CONFIG_GENERIC_HARDIRQS can be removed.
> |
> |     Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
> `----

Introduce wrapper/irq.h to move the feature availability testing logic
into a specific wrapper header. It now tests if the kernel version is
>= 3.12 or if CONFIG_GENERIC_HARDIRQS is defined (for older kernels).
Introduce the lttng-specific CONFIG_LTTNG_HAS_LIST_IRQ to track
availability of this feature within LTTng.

Reported-by: Philippe Mangaud <r49081@freescale.com>
Reported-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

lttng-statedump-impl: Fix lttng_list_interrupts for empty implementation

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Import fix from LTSI: 3.4+ RT kernels use CONFIG_PREEMPT_RT_FULL

Initial LTSI commit:

From: Paul Gortmaker <paul.gortmaker@windriver.com>
> fix reference to obsolete RT Kconfig variable.
>
> The preempt-rt patches no longer use CONFIG_PREEMPT_RT in
> the 3.4 (and newer) versions.  So even though LTSI doesn't
> include RT, having this define present can lead to an easy
> to overlook bug for anyone who does try to layer RT onto
> the LTSI baseline.
>
> Update it to use the currently used define name by RT.
>
> Reported-by: Jim Somerville <Jim.Somerville@windriver.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

Merged with kernel version checks for >= 3.4 to support both old and
newer kernels.

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

Add new tracepoint in KVM

New tracepoint added in kvm: kvm_write_tsc_offset.

Signed-off-by: Mohamad Gebai <mohamad.gebai@polymtl.ca>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Blacklist kernels 3.10.13 and 3.11.2

It looks like my guessing on kernel version at which Greg will pull this
fix was wrong. It will probably appear in the next round of stable
releases.

The fix that needs to reach stable-3.10 and stable-3.11 before we can
remove those from the backlist:

commit 7bd36014460f793c19e7d6c94dab67b0afcfcb7f
Author: John Stultz <john.stultz@linaro.org>
Date:   Wed Sep 11 16:50:56 2013 -0700

    timekeeping: Fix HRTICK related deadlock from ntp lock changes

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: John Stultz <john.stultz@linaro.org>

LTTng trace-clock: shrink kernel blacklist

The lockup fix has been pulled into Linux master as:

commit 7bd36014460f793c19e7d6c94dab67b0afcfcb7f
Author: John Stultz <john.stultz@linaro.org>
Date:   Wed Sep 11 16:50:56 2013 -0700

    timekeeping: Fix HRTICK related deadlock from ntp lock changes

Guessing the stable kernel versions in which this fix will appear in
3.10 and 3.11 stable. 3.12+ are OK.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: John Stultz <john.stultz@linaro.org>

Metadata flush writes data from the cache

When doing a flush on a metadata stream we first check if we can fill
the current subbuffer with data from the cache before doing the actual
flush.

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

Per-stream ioctl to get the current timestamp

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

LTTng ringbuffer ABI calls for index generation

These new calls export the data required for the consumer to generate
the index while tracing :
- timestamp begin
- timestamp end
- events discarded
- context size
- packet size
- stream id

Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Prepare LTTng override of ring buffer fops

This patch allows LTTng to override the file operations of the lib ring
buffer.
For now it does not provide any additional functions, but it prepares
the work of adding LTTng-specific ioctls to the ring buffer.

Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Blacklist Linux kernels 3.10+

Linux kernels 3.10 and 3.11 introduce a deadlock in the timekeeping
subsystem. See
http://lkml.kernel.org/r/1378943457-27314-1-git-send-email-john.stultz@linaro.org
for details. Awaiting patch merge into Linux master, stable-3.10 and
stable-3.11 for fine-grained kernel version blacklisting.

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

Version 2.3.0

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

Fix: metadata stream should not reference session

The metadata stream should only reference the metadata cache, not the
session. Otherwise, we end up in a catch 22 situation:

- Stream POLLHUP is only given when the session is destroyed, but,
- The session is only destroyed when all references to session are
  released, including references from channels, but,
- If the metadata stream holds a reference on the metadata session, we
  end up with a circular dependency loop.

Fix this by making sure the metadata stream does not use any of the
lttng channel nor lttng session.

Reviewed-by: Julien Desfossez <jdesfossez@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: btrfs: support 3.11 Linux kernel

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

statedump: remove KERN_DEBUG messages

They appear to be shown by default in dmesg of many distributions, and
they don't add much value (noisy).

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

Fix: ext4: add missing tracepoints for 3.11 kernel

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

Fix: ext4: Linux 3.11 support

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

Fix: ext3: 3.11 Linux support

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

Fix: statedump nsproxy 3.11 Linux support

Follow upstream Linux change introduced by:

commit c2b1df2eb42978073ec27c99cc199d20ae48b849
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Aug 22 11:39:16 2013 -0700

    Rename nsproxy.pid_ns to nsproxy.pid_ns_for_children

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

Version 2.3.0-rc2

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

Fix: metadata lttng channel refcount

The OOPS at bug #622 is likely caused by a missing reference on the
lttng channel structure, which could lead to accessing the object after
it has been destroyed if the lttng channel file descriptor is closed
while the metadata stream fd is still in use.

Fixes #622

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Julien Desfossez <jdesfossez@efficios.com>

README: lttng-modules incompatible with lttng 0.x patchset

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

Version 2.3.0-rc1

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

Fix: kvm x86 probes side-effect

ccflags-y += -I$(kvm_path)

was causing the lttng-ftrace probe to misbehave.

Fixes #591

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

Fix: allow get/put subbuf in loop for metadata stream

data_pending check can trigger the following sequence:

- get_next_subbuf
- put_subbuf
- get_next_subbuf
- put_subbuf
- get_next_subbuf
- put_subbuf
...

and then finally a thread would consume the data:

- get_next_subbuf
- put_next_subbuf

However, we don't want to populate data from the metadata cache into the
stream until put_next_subbuf is issued. Add a check to ensure that it is
not populated until required.

Also, disallow get_subbuf() ioctl on metadata channel: its random-access
semantic does not play well with serialization of the metadata cache on
demand.

Reviewed-by: Julien Desfossez <jdesfossez@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Add support for kvm x86 specific tracepoints

Two new probes for kvm-x86 and kvm-x86-mmu.

Signed-off-by: Mohamad Gebai <mohamad.gebai@polymtl.ca>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Add mainline headers for kvm x86 tracepoints

Signed-off-by: Mohamad Gebai <mohamad.gebai@polymtl.ca>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Remove old 3.0.4 x86-64 extracted syscall info

Signed-off-by: Yannick Brosseau <yannick.brosseau@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Point the x86-64 overrides to newly extracted 3.10-rc7 files

Signed-off-by: Yannick Brosseau <yannick.brosseau@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Add syscalls extracted files from a 3.10-rc7 kernel

This will add some previously unknown syscalls

Signed-off-by: Yannick Brosseau <yannick.brosseau@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Improve documentation of the syscall extractor script

Signed-off-by: Yannick Brosseau <yannick.brosseau@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: double length of __dynamic_len array

This is required by the newly introduced __dynamic_array_enc_ext_2() and
tp_memcpy_dyn_2().

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

Fix printk instrumentation

- Don't require 2kB of stack anymore (requiring so much kernel stack
  space should be considered as a bug in itself),
- Add support for 3.10 kernel printk instrumentation.

This patch uses "Introduce __dynamic_array_enc_ext_2() and
tp_memcpy_dyn_2()".

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

Introduce __dynamic_array_enc_ext_2() and tp_memcpy_dyn_2()

Allow copying into a single variable-length buffer from two sources.
Needed to fix printk support for Linux kernel < 3.5.

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

Fix: ring buffer: get_subbuf() checks should be performed on "consumed" parameter

This triggers lots of false-positive -EAGAIN errors in flight recorder
snapshots.

Reported-by: Julien Desfossez <jdesfossez@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: SWITCH_FLUSH new sub-buffer checks

The SWITCH_FLUSH, when performed on a completely empty sub-buffer, was
missing some checks (imported from space reservation).

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

Fix: ring buffer: handle concurrent update in nested buffer wrap around check

With stress-test loads that trigger sub-buffer switch very frequently
(small 4kB sub-buffers, frequent flush), we currently observe this kind
of warnings once every few minutes:

[65335.896208] ring buffer relay-overwrite-mmap, cpu 5: records were lost. Caused by:
[65335.896208]   [ 0 buffer full, 1 nest buffer wrap-around, 0 event too big ]

It appears that the check for nested buffer wrap-around does not take
into account that a concurrent execution contexts (either nested for
per-cpu buffers, or from another CPU or nested for global buffers) can
update the commit_count value concurrently.

What we really want to do with this check is to ensure that if we enter
a sub-buffer that had an unbalanced reserve/commit count, assuming there
is no hope that this gets rebalanced promptly, we detect this and drop
the current event. However, in the case where the commit counter has
been concurrently updated by another reserve or a switch, we want to
retry the entire reserve operation.

One way to detect this is to sample the reserve offset twice, around the
commit counter read, along with the appropriate memory barriers.
Therefore, we can detect if the mismatch between reserve and commit
counter is actually caused by a concurrent update, which necessarily has
updated the reserve counter.

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

Cleanup: lib_ring_buffer_switch_new_end() only calls subbuffer_set_data_size()

lib_ring_buffer_switch_new_end() is always called when an event exactly
fills a sub-buffer, which makes padding_size always 0. However, there is
one side-effect that lib_ring_buffer_switch_new_end() needs to have: it
calls subbuffer_set_data_size() to update the size of the data to be
read from the sub-buffer.

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

Revert "Cleanup: ring buffer: remove lib_ring_buffer_switch_new_end()"

This reverts commit 5fb66f07aae4884426f1706d0281bd242a38c2a7.

The equivalent UST commit of this change broke regression tests of
lttng-tools.

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

Fix: handle writes of length 0

lib_ring_buffer_write(), lib_ring_buffer_memset() and
lib_ring_buffer_copy_from_user_inatomic() could be passed a length of 0.
This typically has no side-effect as far as writing into the buffers is
concerned, except for one detail: in overwrite mode, there is a check to
make sure the sub-buffer can be written into. This check is performed
even if length is 0. In the case where this would fall exactly at the
end of a sub-buffer, the check would fail, because the offset would fall
exactly at the beginning of the next sub-buffer.

It triggers this warning:

[65356.890016] ------------[ cut here ]------------
[65356.890016] WARNING: at /home/compudj/git/lttng-modules/wrapper/ringbuffer/../../lib/ringbuffer/../../wrapper/ringbuffer/../../lib/ringbuffer/backend.h:110 lttng_event_write+0x118/0x140 [lttng_ring_buffer_client_mmap_overwrite]()
[65356.890016] Hardware name: X7DAL
[65356.890016] Modules linked in: lttng_probe_writeback(O) lttng_probe_workqueue(O) lttng_probe_vmscan(O) lttng_probe_udp(O) lttng_probe_timer(O) lttng_probe_sunrpc(O) lttng_probe_statedump(O) lttng_probe_sock(O) lttng_probe_skb(O) lttng_probe_signal(O) lttng_probe_scsi(O) lttng_probe_sched(O) lttng_probe_rcu(O) lttng_probe_random(O) lttng_probe_printk(O) lttng_probe_power(O) lttng_probe_net(O) lttng_probe_napi(O) lttng_probe_module(O) lttng_probe_kvm(O) lttng_probe_kmem(O) lttng_probe_jbd2(O) lttng_probe_jbd(O) lttng_probe_irq(O) lttng_probe_ext4(O) lttng_probe_ext3(O) lttng_probe_compaction(O) lttng_probe_btrfs(O) lttng_probe_block(O) lttng_types(O) lttng_ring_buffer_metadata_mmap_client(O) lttng_ring_buffer_client_mmap_overwrite(O) lttng_ring_buffer_client_mmap_discard(O) lttng_ring_buffer_metadata_client(O) lttng_ring_buffer_client_overwrite(O) lttng_ring_buffer_client_discard(O) lttng_tracer(O) lttng_kretprobes(O) lttng_ftrace(O) lttng_kprobes(O) lttng_statedump(O) lttng_lib_ring_buffer(O) cpufreq_ondemand loop e1000e kvm_intel kvm ptp pps_core [last unloaded: lttng_lib_ring_buffer]
[65357.287529] Pid: 0, comm: swapper/7 Tainted: G           O 3.9.4-trace-test #143
[65357.309694] Call Trace:
[65357.317022]  <IRQ>  [<ffffffff8103a3ef>] warn_slowpath_common+0x7f/0xc0
[65357.336893]  [<ffffffff8103a44a>] warn_slowpath_null+0x1a/0x20
[65357.354368]  [<ffffffffa0ff17b8>] lttng_event_write+0x118/0x140 [lttng_ring_buffer_client_mmap_overwrite]
[65357.383025]  [<ffffffffa100134f>] __event_probe__block_rq_with_error+0x1bf/0x220 [lttng_probe_block]
[65357.410376]  [<ffffffff812ea134>] blk_update_request+0x324/0x720
[65357.428364]  [<ffffffff812ea561>] blk_update_bidi_request+0x31/0x90
[65357.447136]  [<ffffffff812eb68c>] blk_end_bidi_request+0x2c/0x80
[65357.465127]  [<ffffffff812eb6f0>] blk_end_request+0x10/0x20
[65357.481822]  [<ffffffff81406b7c>] scsi_io_completion+0x9c/0x670
[65357.499555]  [<ffffffff813fe320>] scsi_finish_command+0xb0/0xe0
[65357.517283]  [<ffffffff81406965>] scsi_softirq_done+0xa5/0x140
[65357.534758]  [<ffffffff812f1d30>] blk_done_softirq+0x80/0xa0
[65357.551710]  [<ffffffff81043b00>] __do_softirq+0xe0/0x440
[65357.567881]  [<ffffffff81043ffe>] irq_exit+0x9e/0xb0
[65357.582754]  [<ffffffff81026465>] smp_call_function_single_interrupt+0x35/0x40
[65357.604388]  [<ffffffff8167be2f>] call_function_single_interrupt+0x6f/0x80
[65357.624976]  <EOI>  [<ffffffff8100ac06>] ? default_idle+0x46/0x300
[65357.643541]  [<ffffffff8100ac04>] ? default_idle+0x44/0x300
[65357.660235]  [<ffffffff8100b899>] cpu_idle+0x89/0xe0
[65357.675109]  [<ffffffff81664911>] start_secondary+0x220/0x227

Always from an event that can write a 0-length field as last field of
its payload, and it always happen directly on a sub-buffer boundary.

While we are there, check for length 0 in lib_ring_buffer_read_cstr()
too.

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

Fix: ring buffer: RING_BUFFER_FLUSH ioctl buffer corruption

lib_ring_buffer_switch_slow() clearly states:

 * Note, however, that as a v_cmpxchg is used for some atomic
 * operations, this function must be called from the CPU which owns the
 * buffer for a ACTIVE flush.

But unfortunately, the RING_BUFFER_FLUSH ioctl does not follow these
important directives. Therefore, whenever the consumer daemon or session
daemon explicitly triggers a "flush" on a buffer, it can race with data
being written to the buffer, leading to corruption of the reserve/commit
counters, and therefore corruption of data in the buffer. It triggers
these warnings for overwrite mode buffers:

[65356.890016] WARNING: at
/home/compudj/git/lttng-modules/wrapper/ringbuffer/../../lib/ringbuffer/../../wrapper/ringbuffer/../../lib/ringbuffer/backend.h:110 lttng_event_write+0x118/0x140 [lttng_ring_buffer_client_mmap_overwrite]()

Which indicates that we are trying to write into a sub-buffer for which
we don't have exclusive access. It also causes the following warnings to
show up:

[65335.896208] ring buffer relay-overwrite-mmap, cpu 5: records were lost. Caused by:
[65335.896208]   [ 0 buffer full, 80910 nest buffer wrap-around, 0 event too big ]

Which is caused by corrupted commit counter.

Fix this by sending an IPI to the CPU owning the flushed buffer for
per-cpu synchronization. For global synchronization, no IPI is needed,
since we allow writes from remote CPUs.

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

Cleanup: ring buffer: remove lib_ring_buffer_switch_new_end()

lib_ring_buffer_switch_new_end() is a leftover from the days where an
event that would exactly fill the current sub-buffer would automatically
trigger a sub-buffer switch into the next sub-buffer.

Even before the ring buffer code has been moved into lttng-modules, this
behavior had been changed: an event that exactly fills a sub-buffer only
fills this current sub-buffer, and does not need to switch into the
next one to populate the sub-buffer header. This change had been done so
periodical timer switch, which shares the same semantic as an event
exactly filling a sub-buffer, would not create tons of empty
sub-buffers.

However, when doing this change, lib_ring_buffer_switch_new_end() has
not been removed, but clearly should have been. Its job is now performed
by the event "commit".

lib_ring_buffer_switch_new_end() has no effect, since padding_size is
always 0.

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

print warning and return -EBUSY on double get_subbuf()

Each get_subbuf() should be paired with a put_subbuf().

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