lttng: syscall instrumentation

x86-32 and x86-64 system call instrumentation, along with the
lttng-syscalls-generate-headers.sh script that generates the headers
from the system call list. See README for details.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng: lib ring buffer clients

Each lttng buffer configuration (discard mode, overwrite mode, mmap
support, splice support, per-cpu buffers, global buffer for metadata) is
a lib ring buffer client.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng: tracer control and core structures

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng: dynamically selectable context information

Events can be augmented with context information. This is dynamically
configurable from the command line.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng: timing calibration feature

This calibration feature is fairly limited for now, but provides an
example of how this can be performed.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng: debugfs and procfs ABI

Add the "lttng" virtual file to debugfs and procfs. All operations are
performed through ioctls (LTTng ioctl range is already reserved
upstream) on this virtual file and on anonymous file descriptors
returned by these ioctls. Each file descriptor is associated with a
tracer "object" (session, channel, stream, event, context).

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng: Add documentation and TODO files

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng: add system call instrumentation probe

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng: probe callbacks

Implement the LTTng probe callbacks. One notable file here is
lttng-events.h, which is the core implementation of the LTTng
TRACE_EVENT macros for generation of probes and tracepoint decription
from the TRACE_EVENT declarations.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng: toplevel Makefile and Kconfig

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
staging: add LTTng to build

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
staging: Add LTTng entry to MAINTAINERS file

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng lib: ring buffer: remove stale null-pointer

* Dan Carpenter <dan.carpenter@oracle.com> wrote:
[...]
> The patch c844b2f5cfea: "lttng lib: ring buffer" from Nov 28, 2011,
> leads to the following Smatch complaint:
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_frontend.c +1150
> +lib_ring_buffer_print_buffer_errors()
>          warn: variable dereferenced before check 'chan' (see line 1143)
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_frontend.c
>   1142  {
>   1143          const struct lib_ring_buffer_config *config =
> +chan->backend.config;
>
> +^^^^^^^^^^^^^^^^^^^^
> Dereference.
>
>   1144          unsigned long write_offset, cons_offset;
>   1145
>   1146          /*
>   1147           * Can be called in the error path of allocation when
>   1148           * trans_channel_data is not yet set.
>   1149           */
>   1150          if (!chan)
>                 ^^^^^^^^^
> Check.  At first glance the comment seems out of date, I think check can
> be removed safely.
>
>   1151                  return;
>   1152          /*

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng lib: ring buffer remove duplicate null pointer

* Dan Carpenter <dan.carpenter@oracle.com> wrote:
> The patch c844b2f5cfea: "lttng lib: ring buffer" from Nov 28, 2011,
> leads to the following Smatch complaint:
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c +33
> +lib_ring_buffer_fault()
>          warn: variable dereferenced before check 'buf' (see line 26)
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c
>     25          struct lib_ring_buffer *buf = vma->vm_private_data;
>     26          struct channel *chan = buf->backend.chan;
>                                        ^^^^^^^^^^^^^^^^^
> Dereference.
>
>     27          const struct lib_ring_buffer_config *config = chan->backend.config;
>     28          pgoff_t pgoff = vmf->pgoff;
>     29          struct page **page;
>     30          void **virt;
>     31          unsigned long offset, sb_bindex;
>     32
>     33          if (!buf)
>                     ^^^^
> Check.
>
>     34                  return VM_FAULT_OOM;
>     35

This check is performed at mapping setup time in
lib_ring_buffer_mmap_buf() already, so we can safely remove this
duplicata.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng lib: ring buffer move null pointer check to open

* Dan Carpenter <dan.carpenter@oracle.com> wrote:
> The patch c844b2f5cfea: "lttng lib: ring buffer" from Nov 28, 2011,
> leads to the following Smatch complaint:
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c +86
> +lib_ring_buffer_mmap_buf()
>          warn: variable dereferenced before check 'buf' (see line 79)
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c
>     78          unsigned long length = vma->vm_end - vma->vm_start;
>     79          struct channel *chan = buf->backend.chan;
>                                        ^^^^^^^^^^^^^^^^^
> Dereference.
>
>     80          const struct lib_ring_buffer_config *config = chan->backend.config;
>     81          unsigned long mmap_buf_len;
>     82
>     83          if (config->output != RING_BUFFER_MMAP)
>     84                  return -EINVAL;
>     85
>     86          if (!buf)
>                     ^^^^
> Check.
>
>     87                  return -EBADF;
>     88

Let's move the NULL buf check to the file "open", where it belongs. The
"open" file operation is the actual interface between lib ring buffer
and the modules using it.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lttng wrapper: add missing include to kallsyms wrapper

Needed to keep bissectability.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
staging: lttng: cleanup one-bit signed bitfields

* Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Sparse complains that these signed bitfields look "dubious".  The
> problem is that instead of being either 0 or 1 like people would expect,
> signed one bit variables like this are either 0 or -1.  It doesn't cause
> a problem in this case but it's ugly so lets fix them.

* walter harms (wharms@bfs.de) wrote:
> hi,
> This patch looks ok to me but this design is ugly by itself.
> It should be replaced by an uchar uint whatever or use a
> real bool (obviously not preferred by this programmes).

bool :1, uchar :1 or uint :1 could make sense. uchar:1/bool:1 won't save
any space here, because the surrounding fields are either uint or
pointers, so alignment will just add padding.

I try to use int/uint whenever possible because x86 CPUs tend to get
less register false-dependencies when using instructions modifying the
whole register (generated by using int/uint types) rather than only part
of it (uchar/char/bool). I only use char/uchar/bool when there is a
clear wanted space gain.

The reason why I never use the bool type within a structure when I want
a compact representation is that bool takes a whole byte just to
represent one bit:

struct usebitfield {
    int a;
    unsigned int f:1, g:1, h:1, i:1, j:1;
    int b;
};

struct usebool {
    int a;
    bool f, g, h, i, j;
    int b;
};

struct useboolbf {
    int a;
    bool f:1, g:1, h:1, i:1, j:1;
    int b;
};

int main()
{
    printf("bitfield %d bytes, bool %d bytes, boolbitfield %d bytes\n",
            sizeof(struct usebitfield), sizeof(struct usebool),
            sizeof(struct useboolbf));
}

result:

bitfield 12 bytes, bool 16 bytes, boolbitfield 12 bytes

This is because each bool takes one byte, while the bitfields are put in
units of "unsigned int" (or bool for the 3rd struct). So in this
example, we need 5 bytes + 3 bytes alignment for the bool, but only 4
bytes to hold the "unsigned int" unit for the bitfields.

The choice between bool and bitfields must also take into account the
frequency of access to the variable, because bitfields require mask
operations to access the selected bit(s). You will notice that none of
these bitfields are accessed on the tracing fast-path: only in
slow-paths. Therefore, space gain is more important than speed here.

One might argue that I have so few of these fields here that it does not
make an actual difference to go for bitfield or bool. I am just trying
to choose types best suited for their intended purpose, ensuring they
are future-proof and will allow simply adding more fields using the same
type, as needed.

So I guess I'll go for uint :1.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
staging: lttng: Fix recent modifications to string_from_user operation

Include: a fix for a recently introduced change: obviously max_t should
be used instead of min_t here. Also, a likely should apply to the result
of the comparison, not the variable per se.

Signed-off-by: Yannick Brosseau <yannick.brosseau@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
staging: lttng: TODO update: lttng reported to work fine on -rt now

The patch "lttng: Fix recent modifications to string_from_user
operation" has been confirmed to fix the corrupted trace problem
experienced on -rt kernel by the original bug reporter. Remove the
entry from the LTTng TODO list.

Reported-by: Yannick Brosseau <yannick.brosseau@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
staging: lttng: Update max symbol length to 256

The user-space tracer, along with the control tools, now support longer
event name strings (up to 256 chars, including \0).

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>