linux-kernel - Re: [PATCH v3 1/7] liblockdep: wrap kernel/lockdep.c to allow usage from userspace

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: <20130204104845.GB24173@gmail.com>
Date:	Mon, 4 Feb 2013 11:48:46 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Sasha Levin <sasha.levin@...cle.com>,
	Arnaldo Carvalho de Melo <acme@...radead.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 v3 1/7] liblockdep: wrap kernel/lockdep.c to allow usage
 from userspace

Ok, these liblockdep bits look really good and clean, and the 
perf integration is obviously useful. It does not conflict with 
any pending tools/perf work either.

Arnaldo, are you fine with:

  b2e7c77a3790 perf: Integrate liblockdep support into perf

?

We could keep it separate in tip:core/locking, no merge into 
tip:perf/core appears to be necessary for the time being.

A couple of suggestions:

1) One thing that is I think is missing is a fun to read 
tools/lib/lockdep/README that explains how to use it all for 
pthread_mutex_t and pthread_rwlock_t checking, and what the 
limitations are (if any).

2) Explicitly mentioning that the code and library is licensed 
under the kernel's GPL would be nice as well, for additional 
clarity - should anyone decide to package it up in distros.

3) Advanced: providing a shell environment variable (LOCKDEP=1?) 
as a way to enable it might be useful as well: that way tools 
could be built with lockdep built in but turned off by default - 
which can be turned on again on demand. It would only constitute 
some data structure overhead, a runtime check in the locking 
wrappers and a bit of an initialization overhead.

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/