lkml.org 
[lkml]   [2013]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 7/9] liblockdep: Support using LD_PRELOAD
On Wed, May 15, 2013 at 11:15:39PM -0400, Sasha Levin wrote:
> +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 (__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
> + */
> +
> + 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(struct lock_lookup));
> +}

Do we still need this with the glibc __pthread_* static initialization?


\
 
 \ /
  Last update: 2013-05-22 12:01    [W:0.818 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site