linux-kernel - Re: [PATCH] lockdep: lock contention tracking

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 21 May 2007 03:19:46 -0700
From:	Bill Huey (hui) <billh@...ppy.monkey.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, Jason Baron <jbaron@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Bill Huey (hui)" <billh@...ppy.monkey.org>
Subject: Re: [PATCH] lockdep: lock contention tracking

On Mon, May 21, 2007 at 11:36:39AM +0200, Ingo Molnar wrote:
> you got the history wrong i think: the first version of lockdep was 
> released to lkml a year ago (May 2006), while the first time you 
> mentioned your lock contention patch was November 2006 and you released 
> it to lkml in December 2006 - so it was _you_ who was "replicating the 
> same work", not lockdep :-) And this was pointed out to you very early 
> on, many months ago.

Yeah, and where do we disagree here again ? So I take it you're disagreeing
with my agreement with you that lockdep came first ? Geez, think about that
one for a bit. (chuckle) :)

I'd like to remind you that I mapped out the lock hierarchy for a fully
preemptive -rt kernel while you and *others* were wanking around with
voluntary preempt remember ? :) Keep in mind, I'm single obsessed with -rt.

[back to the topic]

> and regarding C99 style lock initializers: the -rt project has been 
> removing a whole heap of them in the past 2.5 years, since Oct 2004 or 
> so, and regularly cleansed the upstream kernel for old-style 
> initializers ever since then - so i'm not sure what you are referring 
> to.

Don't worry about it. I did the same work only to realize that there wasn't
much left to convert over.

> btw., you dont even need CONFIG_DEBUG_INFO to get usable symbol names, 
> CONFIG_KALLSYMS alone will do it too. (It's only if you really cannot 
> tell from the lock symbol name and the function name what the entry is 
> about - which is very rare - that you need to look at any debug-info)

I'm anal about these things. I thought that you can do more magic than that
from your previous email, but it just confirms my understanding of how
symbols work already, unless there was a meltdown of the universal physical
laws here or something. That's why I made the choices I did.

The inode initialization code is ambiguous which is why having a specific
line number was very useful. It showed that one of the locks protecting a
tree was heavily hit. There was multipule places in which it could have
been if I hadn't had this information.

Sleep time...

bill

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