[PATCH] tools/liblockdep: change current_obj from thread-local storage to non thread-local storage

[PATCH] tools/liblockdep: change current_obj from thread-local storage to non thread-local storage

[Eunbong Song]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=euc-kr, Size: 1438 bytes --]


current_obj is declared as a thread-local storage.
This prevent to detect locking  problem between multiple threads because
each thread has it's own current_obj. liblockdep can only detect locking problem in a single
thread. However, pthread_mutex_xxx, pthread_rwlock_xxx functions are mainly used for synchro
nization of data between multiple threads.
This patch changes current_obj to non thread-local storage. and current_obj.pid is getting
from getpid system call.

Signed-off-by: Eunbong Song <eunb.song@samsung.com>
---
 tools/lib/lockdep/common.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/lockdep/common.c b/tools/lib/lockdep/common.c
index 8ef602f..6b9a6eb 100644
--- a/tools/lib/lockdep/common.c
+++ b/tools/lib/lockdep/common.c
@@ -5,7 +5,7 @@
 #include <unistd.h>
 #include <sys/syscall.h>
 
-static __thread struct task_struct current_obj;
+static struct task_struct current_obj;
 
 /* lockdep wants these */
 bool debug_locks = true;
@@ -26,7 +26,7 @@ struct task_struct *__curr(void)
 	if (current_obj.pid == 0) {
 		/* Makes lockdep output pretty */
 		prctl(PR_GET_NAME, current_obj.comm);
-		current_obj.pid = syscall(__NR_gettid);
+		current_obj.pid = syscall(__NR_getpid);
 	}
 
 	return &current_obj;
-- 
1.7.0.1
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH] tools/liblockdep: change current_obj from thread-local storage to non thread-local storage

[Sasha Levin]

On 04/23/2015 02:55 AM, Eunbong Song wrote:
> current_obj is declared as a thread-local storage.
> This prevent to detect locking  problem between multiple threads because
> each thread has it's own current_obj. liblockdep can only detect locking problem in a single
> thread. However, pthread_mutex_xxx, pthread_rwlock_xxx functions are mainly used for synchro
> nization of data between multiple threads.
> This patch changes current_obj to non thread-local storage. and current_obj.pid is getting
> from getpid system call.

um... It always worked with threads:

$ cat tests/ABBA_threads.c
#include <liblockdep/mutex.h>
#include "common.h"

pthread_mutex_t a, b;

void *thread_a(void *arg)
{
	LOCK_UNLOCK_2(a, b);

	return NULL;
}

void *thread_b(void *arg)
{
	LOCK_UNLOCK_2(b, a);

	return NULL;
}

void main(void)
{
	pthread_t ta, tb;

	pthread_mutex_init(&a, NULL);
	pthread_mutex_init(&b, NULL);

	pthread_create(&ta, NULL, thread_a, NULL);
	pthread_create(&tb, NULL, thread_b, NULL);

	pthread_join(ta, NULL);
	pthread_join(tb, NULL);
}
$ tests/ABBA_threads

======================================================
[ INFO: possible circular locking dependency detected ]
liblockdep 4.0.0
-------------------------------------------------------
ABBA_threads/12101 is trying to acquire lock:
 (0x10bb700){......}, at: tests/ABBA_threads() [0x401333]

but task is already holding lock:
 (0x10bb680){......}, at: tests/ABBA_threads() [0x401333]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (0x10bb680){......}:
tests/ABBA_threads[0x4019d3]
tests/ABBA_threads[0x4036f6]
tests/ABBA_threads[0x4039c2]
tests/ABBA_threads[0x403fde]
tests/ABBA_threads[0x404aa7]
tests/ABBA_threads[0x405250]
tests/ABBA_threads[0x4053d3]
tests/ABBA_threads[0x4055cd]
tests/ABBA_threads[0x40135d]
tests/ABBA_threads[0x401395]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a5)[0x7f8e6e1dc0a5]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f8e6df09cfd]

-> #0 (0x10bb700){......}:
tests/ABBA_threads[0x4019d3]
tests/ABBA_threads[0x402f51]
tests/ABBA_threads[0x4035c4]
tests/ABBA_threads[0x4039c2]
tests/ABBA_threads[0x403fde]
tests/ABBA_threads[0x404aa7]
tests/ABBA_threads[0x405565]
tests/ABBA_threads(pthread_mutex_lock+0x51)[0x4063fd]
tests/ABBA_threads[0x401333]
tests/ABBA_threads[0x4013c6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a5)[0x7f8e6e1dc0a5]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f8e6df09cfd]

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(0x10bb680);
                               lock(0x10bb700);
                               lock(0x10bb680);
  lock(0x10bb700);

 *** DEADLOCK ***

2 locks held by ABBA_threads/12101:
 #0:  (&b){......}, at: tests/ABBA_threads() [0x4013bc]
 #1:  (0x10bb680){......}, at: tests/ABBA_threads() [0x401333]

stack backtrace:
tests/ABBA_threads[0x4016dd]
tests/ABBA_threads[0x40300b]
tests/ABBA_threads[0x4035c4]
tests/ABBA_threads[0x4039c2]
tests/ABBA_threads[0x403fde]
tests/ABBA_threads[0x404aa7]
tests/ABBA_threads[0x405565]
tests/ABBA_threads(pthread_mutex_lock+0x51)[0x4063fd]
tests/ABBA_threads[0x401333]
tests/ABBA_threads[0x4013c6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a5)[0x7f8e6e1dc0a5]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f8e6df09cfd]


Thanks,
Sasha