linux-kernel - Re: [RFC 1/4] lockdep: additional lock specific information when dumping locks

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: <54B3E466.2030006@oracle.com>
Date:	Mon, 12 Jan 2015 10:12:38 -0500
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	linux-kernel@...r.kernel.org, mingo@...hat.com
Subject: Re: [RFC 1/4] lockdep: additional lock specific information when
 dumping locks

On 01/12/2015 10:06 AM, Peter Zijlstra wrote:
> On Mon, Jan 12, 2015 at 09:57:08AM -0500, Sasha Levin wrote:
>> When dumping held locks, it might be useful to get additional lock-specific
>> information about each lock.
>>
>> This is mainly useful to figure out who really holds each lock rather then
>> who's just waiting on it, but it could be extended further or extended to
>> the other lockdep users if required.
> 
> I really don't see the point in this; I would much rather have something
> useful like:
> 
>  http://lwn.net/Articles/579849/

As far as I can tell, they have completely different purposes.

The reason for my patch is simple: I'm fuzzing with hundreds of worker threads
which at some point trigger a complete system lockup for some reason.

When lockdep dumps the list of held locks it shows that pretty much every one
of those threads is holding the lock which caused the lockup, which is incorrect
because it considers locks in the process of getting acquired as "held".

This is my solution to that issue. I wanted to know which one of the threads is
really holding the lock rather than just waiting on it.

Is there a better way to solve that problem?

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/