linux-kernel - Re: [Patch v5 0/9] liblockdep: userspace lockdep

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]

Message-ID: <20130626155325.GB7399@gmail.com>
Date:	Wed, 26 Jun 2013 17:53:25 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Sasha Levin <sasha.levin@...cle.com>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [Patch v5 0/9] liblockdep: userspace lockdep


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Thu, Jun 13, 2013 at 06:41:15PM -0400, Sasha Levin wrote:
> > liblockdep is a tiny wrapper built around kernel/lockdep.c. The aim is to
> > provide the same functionality the kernel gets from lockdep to userspace.
> > 
> > The bulk of the code here is the LD_PRELOAD support which provides users
> > an easy way to test their code without having to integrate liblockdep into
> > said code. Simply doing:
> > 
> >         lockdep my_app
> > 
> > Would provide lockdep support to my_app.
> > 
> > There is also a small test suite to test both mutexes and rwlocks, it's
> > based on the tests in lib/locking-selftest.c.
> > 
> > This entire patch series was reviewed by lockdep maintainers and accepted to
> > the tip tree previously. It was pulled out so that the potential merge of
> > liblockdep won't delay the rest of the commits in the tip locking tree.
> > 
> > For some more background about this entire thing, the folks at LWN did
> > an awesome overview: http://lwn.net/Articles/536363/
> > 
> 
> Ingo, I don't think I see anything holding this back; however I remember 
> reading some email about people not liking stuff like this living in the 
> tools/ directory or such.
> 
> Will you pick this up?

So I'd really be interested in how interesting/useful this is to userspace 
developers? Does it work for something complex as Firefox, or Apache, to 
the extent they make use of these locking APIs?

'people' not liking the in-tree solution was for example Linus, who's on 
Cc:, so if Linus you still have a strong opinion against it I won't merge 
it against you.

Thanks,

	Ingo
--
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/