linux-kernel - Re: [PATCH 2/7] liblock: public headers for mutex implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <510BCF29.7000104@oracle.com>
Date:	Fri, 01 Feb 2013 09:20:25 -0500
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	mingo@...hat.com, peterz@...radead.org, paulus@...ba.org,
	acme@...stprotocols.net, penberg@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] liblock: public headers for mutex implementation

On 02/01/2013 04:57 AM, Ingo Molnar wrote:
> 
> * Sasha Levin <sasha.levin@...cle.com> wrote:
> 
>> These headers provide the same API as their pthread mutex counterparts.
>>
>> The design here is to allow to easily switch to liblock lock validation
>> just by adding a "liblock_" to pthread_mutex_*() calls, which means that
>> it's easy to integrate liblock into existing codebases.
> 
> I'd suggest to name the user-space counterpart 'liblockdep', to 
> make it clear that this is user-space lockdep.

Agreed. Pekka also mentioned that liblock sounds to much like lib-block, so
renaming it to liblockdep will take care of that :)

> Regarding pthread_mutex_t checking, I think what we *really* 
> want is a wrapper that can be activated via:
> 
> #define __USE_LIBLOCKDEP
> 
> And which then takes over the pthread primitives via:
> 
>   #define pthread_mutex_lock liblockdep_pthread_mutex_lock
> 
> or so.
> 
> That way the source code only needs a __USE_LIBLOCKDEP in one or 
> two key places and checking is activated.

There are 2 issues I see with that:
 - api calls which are liblockdep specific (liblockdep_init() for example) would
still have to be wrapped somehow in the new code.
 - LIBLOCKDEP_PTHREAD_MUTEX_INIT(mtx) doesn't only change the name of the original
pthread mutex initializer, it also starts requiring the mutex name as parameter so
that it could pass it on to lockdep.

Dealing with these two will mean that there's a '#ifdef __USE_LIBLOCKDEP' both in
the lib and in the source code that uses it, which might be a bit confusing.

Either way, I'll resend the patch with these changes so we'll have a better view
of how it would look.


Thanks,
Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/