On Thu, May 09, 2013 at 11:58:07AM -0400, Sasha Levin wrote:
> + /*
> + * Some programs attempt to initialize and use locks in their
> + * allocation path. This means that a call to malloc() would
> + * result in locks being initialized and locked.
> + *
> + * Why is it an issue for us? dlsym() below will try allocating to
> + * give us the original function. Since this allocation will result
> + * in a locking operations, we have to let pthread deal with it,
> + * but we can't! we don't have the pointer to the original API
> + * since we're inside dlsym() trying to get it :(
> + *
> + * We can work around it by telling the program that locking was
> + * really okay, and just initialize those locks when we're fully
> + * up and running (this is ok because this all happens during
> + * initialization phase, when we have just one thread). But
> + * this is a big TODO at this point.
> + */
> + if (preload_started) {
> + printf(
> + "LOCKDEP error: It seems that the program you are trying to "
> + "debug is initializing locks in it's allocation path.\n"
> + "This means that liblockdep cannot reliably analyze this "
> + "program since we need the allocator to work before we can "
> + "debug locks.\nSorry!\n");
> +
> + exit(1);
> + }
Would something like the below cure things? Obviously this hasn't been near a
compiler for the entire thing still isn't wanting to compile for me.
---
--- a/tools/lib/lockdep/preload.c
+++ b/tools/lib/lockdep/preload.c
@@ -1,4 +1,5 @@
#define _GNU_SOURCE
+#include <sysexits.h>
#include <pthread.h>
#include <stdio.h>
#include <dlfcn.h>
@@ -46,11 +47,12 @@ static int (*ll_pthread_rwlock_trywrlock
static int (*ll_pthread_rwlock_wrlock)(pthread_rwlock_t *rwlock);
static int (*ll_pthread_rwlock_unlock)(pthread_rwlock_t *rwlock);
-static bool preload_done;
+enum { none, prepare, done, } __init_state;
+
static void init_preload(void);
static void try_init_preload(void)
{
- if (!preload_done)
+ if (__init_state != done)
init_preload();
}
@@ -76,6 +78,54 @@ static struct rb_node **__get_lock_node(
return node;
}
+#ifndef LIBLOCKDEP_STATIC_ENTRIES
+#define LIBLOCKDEP_STATIC_ENTRIES 1024
+#endif
+
+static struct lock_lookup __locks[LIBLOCKDEP_STATIC_ENTRIES];
+static int __locks_nr;
+
+static inline bool is_static_lock(struct lock_lookup *lock)
+{
+ return lock >= __locks && lock < __locks + ARRAY_SIZE(__locks);
+}
+
+static struct lock_lookup *alloc_lock(void)
+{
+ if (unlikely(__init_state != done)) {
+ /*
+ * Some programs attempt to initialize and use locks in their
+ * allocation path. This means that a call to malloc() would
+ * result in locks being initialized and locked.
+ *
+ * Why is it an issue for us? dlsym() below will try allocating
+ * to give us the original function. Since this allocation will
+ * result in a locking operations, we have to let pthread deal
+ * with it, but we can't! we don't have the pointer to the
+ * original API since we're inside dlsym() trying to get it :(
+ */
+
+ /* XXX: can we be concurrent already? if so add lock */
+
+ int idx = __locks_nr++;
+ if (idx >= ARRAY_SIZE(__locks)) {
+ fprintf(stderr,
+ "LOCKDEP error: insufficient LIBLOCKDEP_STATIC_ENTRIES\n");
+
+ exit(EX_UNAVAILABLE);
+ }
+ return __locks + idx;
+ }
+
+ return malloc(sizeof(*lock));
+}
+
+static inline void free_lock(struct lock_lookup *lock)
+{
+ if (likely(!is_static_lock(lock)))
+ free(lock);
+}
+
/**
* __get_lock - find or create a lock instance
* @lock: pointer to a pthread lock function
@@ -96,7 +146,7 @@ static struct lock_lookup *__get_lock(vo
}
/* We didn't find the lock, let's create it */
- l = malloc(sizeof(*l));
+ l = alloc_lock();
if (l == NULL)
return NULL;
@@ -125,7 +175,7 @@ static void __del_lock(struct lock_looku
ll_pthread_rwlock_wrlock(&locks_rwlock);
rb_erase(&lock->node, &locks);
ll_pthread_rwlock_unlock(&locks_rwlock);
- free(lock);
+ free_lock(lock);
}
int pthread_mutex_init(pthread_mutex_t *mutex,
@@ -329,40 +379,10 @@ int pthread_rwlock_unlock(pthread_rwlock
__attribute__((constructor)) static void init_preload(void)
{
- static bool preload_started;
-
- if (preload_done)
+ if (__init_state != done)
return;
- /*
- * Some programs attempt to initialize and use locks in their
- * allocation path. This means that a call to malloc() would
- * result in locks being initialized and locked.
- *
- * Why is it an issue for us? dlsym() below will try allocating to
- * give us the original function. Since this allocation will result
- * in a locking operations, we have to let pthread deal with it,
- * but we can't! we don't have the pointer to the original API
- * since we're inside dlsym() trying to get it :(
- *
- * We can work around it by telling the program that locking was
- * really okay, and just initialize those locks when we're fully
- * up and running (this is ok because this all happens during
- * initialization phase, when we have just one thread). But
- * this is a big TODO at this point.
- */
- if (preload_started) {
- printf(
- "LOCKDEP error: It seems that the program you are trying to "
- "debug is initializing locks in it's allocation path.\n"
- "This means that liblockdep cannot reliably analyze this "
- "program since we need the allocator to work before we can "
- "debug locks.\nSorry!\n");
-
- exit(1);
- }
-
- preload_started = true;
+ __init_state = prepare;
ll_pthread_mutex_init = dlsym(RTLD_NEXT, "pthread_mutex_init");
ll_pthread_mutex_lock = dlsym(RTLD_NEXT, "pthread_mutex_lock");
@@ -380,5 +400,5 @@ __attribute__((constructor)) static void
lockdep_init();
- preload_done = true;
+ __init_state = done;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
