All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: torvalds@linux-foundation.org, mingo@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/9] liblockdep: Add public headers for pthread_mutex_t implementation
Date: Wed, 22 May 2013 11:22:32 +0200	[thread overview]
Message-ID: <20130522092232.GF18810@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1368674141-10796-4-git-send-email-sasha.levin@oracle.com>

On Wed, May 15, 2013 at 11:15:35PM -0400, Sasha Levin wrote:
> These headers provide the same API as their pthread mutex
> counterparts.
> 
> The design here is to allow to easily switch to liblockdep lock
> validation just by adding a "liblockdep_" to pthread_mutex_*()
> calls, which means that it's easy to integrate liblockdep into
> existing codebases.
> 
> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
> ---
>  tools/lib/lockdep/include/liblockdep/common.h | 42 ++++++++++++++++
>  tools/lib/lockdep/include/liblockdep/mutex.h  | 70 +++++++++++++++++++++++++++
>  2 files changed, 112 insertions(+)
>  create mode 100644 tools/lib/lockdep/include/liblockdep/common.h
>  create mode 100644 tools/lib/lockdep/include/liblockdep/mutex.h
> 
> diff --git a/tools/lib/lockdep/include/liblockdep/common.h b/tools/lib/lockdep/include/liblockdep/common.h
> new file mode 100644
> index 0000000..1113cad
> --- /dev/null
> +++ b/tools/lib/lockdep/include/liblockdep/common.h
> @@ -0,0 +1,42 @@
> +#ifndef _LIBLOCKDEP_COMMON_H
> +#define _LIBLOCKDEP_COMMON_H
> +
> +#include <pthread.h>
> +
> +#ifndef _THIS_IP_

#ifndef _RET_IP_ ?

> +#define _RET_IP_ (unsigned long)__builtin_return_address(0)
> +#endif
> +
> +#define NR_LOCKDEP_CACHING_CLASSES 2
> +#define MAX_LOCKDEP_SUBCLASSES 8UL
> +
> +struct lockdep_subclass_key {
> +	char __one_byte;
> +};
> +
> +struct lock_class_key {
> +	struct lockdep_subclass_key subkeys[MAX_LOCKDEP_SUBCLASSES];
> +};
> +
> +struct lockdep_map {
> +	struct lock_class_key	*key;
> +	struct lock_class	*class_cache[NR_LOCKDEP_CACHING_CLASSES];
> +	const char		*name;
> +#ifdef CONFIG_LOCK_STAT
> +	int			cpu;
> +	unsigned long		ip;
> +#endif
> +};
> +
> +void lockdep_init_map(struct lockdep_map *lock, const char *name,
> +			struct lock_class_key *key, int subclass);
> +void lock_acquire(struct lockdep_map *lock, unsigned int subclass,
> +			int trylock, int read, int check,
> +			struct lockdep_map *nest_lock, unsigned long ip);
> +void lock_release(struct lockdep_map *lock, int nested,
> +			unsigned long ip);
> +
> +#define STATIC_LOCKDEP_MAP_INIT(_name, _key) \
> +	{ .name = (_name), .key = (void *)(_key), }
> +
> +#endif
> diff --git a/tools/lib/lockdep/include/liblockdep/mutex.h b/tools/lib/lockdep/include/liblockdep/mutex.h
> new file mode 100644
> index 0000000..c342f70
> --- /dev/null
> +++ b/tools/lib/lockdep/include/liblockdep/mutex.h
> @@ -0,0 +1,70 @@
> +#ifndef _LIBLOCKDEP_MUTEX_H
> +#define _LIBLOCKDEP_MUTEX_H
> +
> +#include <pthread.h>
> +#include "common.h"
> +
> +struct liblockdep_pthread_mutex {
> +	pthread_mutex_t mutex;
> +	struct lockdep_map dep_map;
> +};
> +
> +typedef struct liblockdep_pthread_mutex liblockdep_pthread_mutex_t;
> +
> +#define LIBLOCKDEP_PTHREAD_MUTEX_INITIALIZER(mtx)			\
> +		(const struct liblockdep_pthread_mutex) {		\
> +	.mutex = PTHREAD_MUTEX_INITIALIZER,				\
> +	.dep_map = STATIC_LOCKDEP_MAP_INIT(#mtx, &((&(mtx))->dep_map)),	\
> +}
> +
> +static inline int __mutex_init(liblockdep_pthread_mutex_t *lock,
> +				const char *name,
> +				struct lock_class_key *key,
> +				const pthread_mutexattr_t *__mutexattr)
> +{
> +	lockdep_init_map(&lock->dep_map, name, key, 0);
> +	return pthread_mutex_init(&lock->mutex, __mutexattr);
> +}
> +
> +#define liblockdep_pthread_mutex_init(mutex, mutexattr)		\
> +({								\
> +	static struct lock_class_key __key;			\
> +								\
> +	__mutex_init((mutex), #mutex, &__key, (mutexattr));	\
> +})

OK, so people using liblockdep_pthread_mutex_init() do get the 'normal'
class rules.

> +
> +static inline int liblockdep_pthread_mutex_lock(liblockdep_pthread_mutex_t *lock)
> +{
> +	lock_acquire(&lock->dep_map, 0, 0, 0, 2, NULL, (unsigned long)_RET_IP_);
> +	return pthread_mutex_lock(&lock->mutex);
> +}

They will however then also want all the 'normal' lockdep annotations to
deal with that like:

liblockdep_pthread_mutex_lock_nested()
liblockdep_pthread_mutex_lock_nest_lock()

*phew* and here I always though pthread_mutex_* was a long prefix...

Also, the above doesn't have the full lockstat contention hooks -- not
sure that's on purpose or not.

> +
> +static inline int liblockdep_pthread_mutex_unlock(liblockdep_pthread_mutex_t *lock)
> +{
> +	lock_release(&lock->dep_map, 0, (unsigned long)_RET_IP_);
> +	return pthread_mutex_unlock(&lock->mutex);
> +}
> +
> +static inline int liblockdep_pthread_mutex_trylock(liblockdep_pthread_mutex_t *lock)
> +{
> +	lock_acquire(&lock->dep_map, 0, 1, 0, 2, NULL, (unsigned long)_RET_IP_);
> +	return pthread_mutex_trylock(&lock->mutex) == 0 ? 1 : 0;
> +}
> +
> +static inline int liblockdep_pthread_mutex_destroy(liblockdep_pthread_mutex_t *lock)
> +{
> +	return pthread_mutex_destroy(&lock->mutex);
> +}
> +
> +#ifdef __USE_LIBLOCKDEP
> +
> +#define pthread_mutex_t         liblockdep_pthread_mutex_t
> +#define pthread_mutex_init      liblockdep_pthread_mutex_init
> +#define pthread_mutex_lock      liblockdep_pthread_mutex_lock
> +#define pthread_mutex_unlock    liblockdep_pthread_mutex_unlock
> +#define pthread_mutex_trylock   liblockdep_pthread_mutex_trylock
> +#define pthread_mutex_destroy   liblockdep_pthread_mutex_destroy

Given the liblockdep_* things use 'proper' classes do you want this
mapping? If you do, should we use the same alias nonsense glibc uses or
are CPP macros good enough for us?

  reply	other threads:[~2013-05-22  9:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16  3:15 [PATCH v4 0/9] liblockdep: userspace lockdep Sasha Levin
2013-05-16  3:15 ` [PATCH v4 1/9] lockdep: Be nice about building from userspace Sasha Levin
2013-05-16  7:32   ` Pekka Enberg
2013-05-16  3:15 ` [PATCH v4 2/9] liblockdep: Wrap kernel/lockdep.c to allow usage " Sasha Levin
2013-05-22  9:14   ` Peter Zijlstra
2013-05-22  9:17   ` Peter Zijlstra
2013-05-28 19:30     ` Sasha Levin
2013-05-29 11:11       ` Peter Zijlstra
2013-05-16  3:15 ` [PATCH v4 3/9] liblockdep: Add public headers for pthread_mutex_t implementation Sasha Levin
2013-05-22  9:22   ` Peter Zijlstra [this message]
2013-05-28 19:33     ` Sasha Levin
2013-05-29 11:14       ` Peter Zijlstra
2013-05-16  3:15 ` [PATCH v4 4/9] liblockdep: Add pthread_mutex_t test suite Sasha Levin
2013-05-16  3:15 ` [PATCH v4 5/9] liblockdep: Add public headers for pthread_rwlock_t implementation Sasha Levin
2013-05-22  9:23   ` Peter Zijlstra
2013-05-16  3:15 ` [PATCH v4 6/9] liblockdep: Add pthread_rwlock_t test suite Sasha Levin
2013-05-16  3:15 ` [PATCH v4 7/9] liblockdep: Support using LD_PRELOAD Sasha Levin
2013-05-22  9:24   ` Peter Zijlstra
2013-05-28 19:35     ` Sasha Levin
2013-05-29 11:15       ` Peter Zijlstra
2013-05-22  9:27   ` Peter Zijlstra
2013-05-28 19:38     ` Sasha Levin
2013-05-29 11:16       ` Peter Zijlstra
2013-05-16  3:15 ` [PATCH v4 8/9] liblockdep: Add the 'lockdep' user-space utility Sasha Levin
2013-05-22  9:27   ` Peter Zijlstra
2013-05-16  3:15 ` [PATCH v4 9/9] liblockdep: Add a MAINTAINERS entry Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130522092232.GF18810@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=sasha.levin@oracle.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.