Jeff Layton | 25 Apr 23:29 2015
Picon

cds_lfht_count_nodes always returns -1 for before/after counts

Hi, I have some code using the cds_lfht infrastructure, and recently
added a function to check to see if the table was empty using
cds_lfht_count_nodes. That function just does this:

        rcu_read_lock();
        cds_lfht_count_nodes(ht, &before, &count, &after);
        rcu_read_unlock();

What I've found though is that when the table is empty and I know that
there are no concurrent inserts going on, the before and after counters
are always set to -1 after this call.

Is that expected behavior? For the record, I'm using this package from
the Fedora 21 repos:

    userspace-rcu-0.8.1-5.fc21.x86_64

Thanks in advance!
--

-- 
Jeff Layton <jlayton <at> poochiereds.net>
Mathieu Desnoyers | 25 Apr 17:52 2015

[PATCH] Fix: deadlock when thread join is issued in read-side C.S. (v2)

The transitive dependency between:

RCU read-side C.S. -> synchronize_rcu -> rcu_gp_lock -> rcu_register_thread

and the dependency:

pthread_join -> awaiting for thread completion

Can block a thread on join, and thus have the side-effect of deadlocking
a thread doing a pthread_join while within a RCU read-side critical
section. This join would be awaiting for completion of register_thread or
rcu_unregister_thread, which may never complete because the rcu_gp_lock
is held by synchronize_rcu executed from another thread.

One solution to fix this is to add a new lock, rcu_registry_lock. This
lock now protects the thread registry. It is released between iterations
on the registry by synchronize_rcu, thus allowing thread
registration/unregistration to complete even though synchronize_rcu is
awaiting for RCU read-side critical sections to complete.

Changes since v1:
- Hold both rcu_gp_lock and rcu_registry_lock across fork in urcu-bp.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers <at> efficios.com>
CC: Eugene Ivanov <Eugene.Ivanov <at> orc-group.com>
CC: Paul E. McKenney <paulmck <at> linux.vnet.ibm.com>
CC: Lai Jiangshan <laijs <at> cn.fujitsu.com>
CC: Stephen Hemminger <stephen <at> networkplumber.org>
---
 urcu-bp.c   | 49 +++++++++++++++++++++++++++++++++++++++--------
(Continue reading)

Marc Khouzam | 24 Apr 16:14 2015
Picon

[PATCH] Provide tcsh completion

The new script 'lttng-tcsh_completion' is provided to allow
command-completion for the tcsh shell.

The approach taken by this script is to to re-use the advanced bash
completion script and use its result for tcsh completion.  This is
achieved by running the bash script and outputting the completion
result for tcsh consumption.

This approach is based on a similar script used in the git project.

To use this completion script:

   0) You need tcsh 6.16.00 or newer.
   1) Copy both this file and the bash completion script to ${HOME}.
      You _must_ use the name ${HOME}/.lttng-bash_completion for the
      bash script.
      (e.g. ~/.lttng-tcsh_completion and ~/.lttng-bash_completion).
   2) Add the following line to your .tcshrc/.cshrc:
       source ~/.lttng-tcsh_completion
   3) For completion similar to bash, it is recommended to also
      add the following line to your .tcshrc/.cshrc:
       set autolist=ambiguous
      It will tell tcsh to list the possible completion choices.

Signed-off-by: Marc Khouzam <marc.khouzam <at> gmail.com>
---
 extras/lttng-tcsh_completion |  163 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 163 insertions(+)
 create mode 100755 extras/lttng-tcsh_completion

(Continue reading)

Jesper Derehag | 24 Apr 10:48 2015
Picon

singleton tracepoints?

Hi,

I have been thinking a little bit about if there is some way to both define/implement and call tracepoints in
a single call.

Normally, defining tracepoints goes something along these lines:
1. Define tracepoint in tp.h 
        TRACE_EVENT(..)
2. Generate probes in tp.c
       &define TRACEPOINT_CREATE_PROBES
       &include "tp.h"
3. Call tracepoint in main.c
       tracepoint(...);

Obviously you could join points 1&2 if you use lttng-gen-tp. It requires that you have a tracepoint
definintioin file somewhere.

So the use case would then be to both "define" and call tracepoints in a single call.
I was thinking of something like this:

(Bad name, I know..)
singleton_tracepoint(TRACE_WARN, provider, name, const char*, "Something bad has happened!");

So the hard question then, how could we implement this?

I have so far thought of 4 possible approaches (and they are really not very well thought through, kind of
brainstorming here):

1. Continue with the macro-magic as previously used tracepoint-event.h
    Cant think of any way to make this work. tracepoint-event.h hevaily relies on recursively including
(Continue reading)

Mathieu Desnoyers | 24 Apr 00:29 2015

LTTng modules kernels supported now 2.6.36 to 4.0+

Hi,

We have updated the LTTng modules readme files to
document that kernels below 2.6.36 are not supported
anymore. Linux 2.6.36 was released back in October
2010, so supporting roughly 5 years of kernel versions
seems to be enough. There was previously partial support
in older LTTng modules versions for kernels 2.6.32 to
2.6.35 with a few patches needed.

If this is a major inconvenience, please let us know.

Thanks!

Mathieu

--

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Mathieu Desnoyers | 23 Apr 23:07 2015

Debian 3.16.7-ckt9-2 issue with lttng-modules kmem probe

Hi Jon,

It appears that lttng-modules cannot build on the
Debian kernel 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13)
x86_64 GNU/Linux.

It appears that their exported kmem.h header differs from
the upstream stable branch, but AFAIK there is no Debian-specific
version number available to distinguish between upstream stable
and the Debian kernel.

We have been hit by this in the past for Ubuntu kernels, and the
solution has been to introduce a UTS_UBUNTU_RELEASE_ABI define
into their kernels, which can be used to follow their own kernel
versions.

Do you think we could ask Debian to do the same ?

Thanks!

Mathieu

--

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Mathieu Desnoyers | 23 Apr 20:10 2015

[RFC PATCH urcu] Fix: deadlock when thread join is issued in read-side C.S.

The transitive dependency between:

RCU read-side C.S. -> synchronize_rcu -> rcu_gp_lock -> rcu_register_thread

and the dependency:

pthread_join -> awaiting for thread completion

Can block a thread on join, and thus have the side-effect of making a
thread doing a pthread_join while within a RCU read-side critical
section deadlock, awaiting for completion of register_thread or
rcu_unregister_thread, which may never complete because the rcu_gp_lock
is held by synchronize_rcu.

One solution to fix this is to add a new lock, rcu_registry_lock. This
lock now protects the thread registry. It is released between iterations
on the registry by synchronize_rcu, thus allowing thread
registration/unregistration to complete even though synchronize_rcu is
awaiting for RCU read-side critical sections to complete.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers <at> efficios.com>
CC: Eugene Ivanov <Eugene.Ivanov <at> orc-group.com>
CC: Paul E. McKenney <paulmck <at> linux.vnet.ibm.com>
CC: Lai Jiangshan <laijs <at> cn.fujitsu.com>
CC: Stephen Hemminger <stephen <at> networkplumber.org>
---
 urcu-bp.c   | 54 ++++++++++++++++++++++++++++++++++++++++------------
 urcu-qsbr.c | 38 +++++++++++++++++++++++++++++++++----
 urcu.c      | 63 ++++++++++++++++++++++++++++++++++++++++++++++++-------------
 3 files changed, 126 insertions(+), 29 deletions(-)
(Continue reading)

Jérémie Galarneau | 23 Apr 19:07 2015

[PATCH lttng-ust] Fix: Don't wait during registration if clock_gettime() fails

get_constructor_timeout() currently returns -1 which, according to
the lttng-ust(3) man page and lttng_ust_init() implementation,
"waits forever".

This changes the behavior to match what is expressed in the comments.

Comments in get_constructor_timeout() and get_timeout() are also
modified to match the following convention:

-1: wait forever
0: don't wait
1: wait for "constructor_delay_ms"

Signed-off-by: Jérémie Galarneau <jeremie.galarneau <at> efficios.com>
---
 liblttng-ust/lttng-ust-comm.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/liblttng-ust/lttng-ust-comm.c b/liblttng-ust/lttng-ust-comm.c
index 14bbb96..52dc2da 100644
--- a/liblttng-ust/lttng-ust-comm.c
+++ b/liblttng-ust/lttng-ust-comm.c
 <at>  <at>  -402,7 +402,7  <at>  <at>  int setup_local_apps(void)

 /*
  * Get notify_sock timeout, in ms.
- * -1: don't wait. 0: wait forever. >0: timeout, in ms.
+ * -1: wait forever. 0: don't wait. >0: timeout, in ms.
  */
 static
(Continue reading)

Hannes Weisbach | 23 Apr 12:04 2015
Picon

[BUG] lttng-sessiond

Hello,

I'm using LTTng with a kernel that has lock debugging enabled.  I
familiarized myself with LTTng using the "Hello world" example, where
I encountered two bugs.

1) Using multiple probes for the lttng-sessiond arguments
--kmod-probes and --extra-kmod-probes does not work:

$ sudo lttng-sessiond --kmod-probes="hello,sched" -vvv
[...]
DEBUG1 - 11:54:22.413830 [17827/17827]: Modprobe successfully lttng-probe-sched (in
modprobe_lttng() at modprobe.c:285)
sh: 1: Syntax error: "(" unexpected
DEBUG1 - 11:54:22.415273 [17827/17827]: Unable to load optional module (null); continuing (in
modprobe_lttng() at modprobe.c:281)
[...]

$ sudo lttng-sessiond --kmod-probes="sched,hello" -vvv
[...]
DEBUG1 - 11:55:13.879976 [17896/17896]: Modprobe successfully lttng-probe-hello (in
modprobe_lttng() at modprobe.c:285)
sh: 1: Syntax error: "(" unexpected
DEBUG1 - 11:55:13.881183 [17896/17896]: Unable to load optional module (null); continuing (in
modprobe_lttng() at modprobe.c:281)
[...]

$ sudo lttng-sessiond --extra-kmod-probes="sched,hello" -vvv
[...]
DEBUG1 - 11:55:54.244515 [17966/17966]: Modprobe successfully lttng-probe-hello (in
(Continue reading)

Jonathan Rajotte | 22 Apr 21:39 2015

[PATCH lttng-tools] Man page: reference lttng-crash under --shm-path option

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien <at> efficios.com>
---
 doc/man/lttng.1 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/man/lttng.1 b/doc/man/lttng.1
index e077b09..4b40a62 100644
--- a/doc/man/lttng.1
+++ b/doc/man/lttng.1
 <at>  <at>  -312,6 +312,8  <at>  <at>  Path where shared memory holding buffers should be created. Useful
 when used with PRAMFS or other persistent memory filesystems to extract
 trace data in the event of a crash requiring a reboot.

+See the \fBlttng-crash(1)\fP utility for more information on crash recovery.
+
 .TP
 .BR "\-U, \-\-set-url=URL"
 Set URL for the consumer output destination. It is persistent for the
 <at>  <at>  -1116,6 +1118,7  <at>  <at>  found.
 .BR lttng-ust(3),
 .BR lttng-sessiond(8),
 .BR lttng-relayd(8),
+.BR lttng-crash(1),

 .SH "BUGS"

--

-- 
2.1.4
Anand Neeli | 22 Apr 20:56 2015
Picon

lttng-relayd core at relay_close_stream

Hi,
I see following relayd core in 2.6
is there any fix or is this a known issue?

(gdb) bt
#0  0x00007fccd7d54ff9 in __GI_raise (sig=sig <at> entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007fccd7d58068 in __GI_abort () at abort.c:89
#2  0x00007fccd7d4e146 in __assert_fail_base (
    fmt=0x7fccd7e86230 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion <at> entry=0x4209da "ctf_trace", file=file <at> entry=0x4209bf "main.c", line=line <at> entry=737, 
    function=function <at> entry=0x4237a0 <__PRETTY_FUNCTION__.9535> "try_close_stream") at assert.c:92
#3  0x00007fccd7d4e1f2 in __GI___assert_fail (assertion=assertion <at> entry=0x4209da "ctf_trace", 
    file=file <at> entry=0x4209bf "main.c", line=line <at> entry=737, 
    function=function <at> entry=0x4237a0 <__PRETTY_FUNCTION__.9535> "try_close_stream") at assert.c:101
#4  0x00000000004079f0 in try_close_stream (session=0x7fccc801c780, stream=0x7fccc8024500) at main.c:737
#5  0x0000000000408e8b in relay_close_stream (recv_hdr=0x7fccd61e9b40, conn=0x7fcccc000ec0) at main.c:1360
#6  relay_process_control (recv_hdr=recv_hdr <at> entry=0x7fccd61e9c60, conn=0x7fcccc000ec0) at main.c:2106
#7  0x000000000040a9e3 in relay_thread_worker (data=<optimized out>) at main.c:2564
#8  0x00007fccd80d1fe3 in start_thread (arg=0x7fccd61ea700) at pthread_create.c:312
#9  0x00007fccd7e07afd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111


Thanks,
Anand Neeli

_______________________________________________
lttng-dev mailing list
lttng-dev <at> lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Gmane