linux-kernel - Re: [PATCH v3 7/9] liblockdep: Support using LD

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 May 2013 12:06:46 -0400
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	torvalds@...ux-foundation.org, mingo@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 7/9] liblockdep: Support using LD_PRELOAD

On 05/10/2013 09:57 AM, Peter Zijlstra wrote:
> So you're doing instance tracking and not creating classes like the kernel
> lockdep does? While that reduces false positives it also greatly reduces the
> effectiveness of lockdep.
> 
> The power of lock-classes is that it increases the chance of catching potential
> deadlocks without there ever actually being a deadlock.

Originally I had classes working as you've pointed out, until the first time I've
tried running lockdep on qemu.

They appear to have wrappers for every api call known to man, including all the
posix locking apis.

Basically, instead of directly calling pthread_mutex_lock() for example, there's
a wrapper named qemu_mutex_lock() that calls the api above:

	void qemu_mutex_lock(QemuMutex *mutex)
	{
	    int err;

	    err = pthread_mutex_lock(&mutex->lock);
	    if (err)
	        error_exit(err, __func__);
	}

So as you might imagine, the first time I ran it my log exploded with warnings.

I've poked around the source of other big projects, and the example above is
somewhat common with projects that wrap everything to be compatible with different
architectures or apis - which is something that doesn't happen in the kernel.

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/