linux-kernel - Question about lock sequence

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

Date:	Sat, 10 Apr 2010 19:44:07 +0900
From:	Hitoshi Mitake <mitake@....info.waseda.ac.jp>
To:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frederic Weisbecker <fweisbec@...il.com>
CC:	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Question about lock sequence

Hi,

I found that my understand about lockdep is completely wrong :( ,
so state machine of perf lock should be fixed before optimization.

And I found that behaviour related to some of spin locks are strange.
The concrete example is lock sequences targeting dcache_lock (defined in
head of fs/dcache.c).

I made a little (and not essential) change to perf lock, and observe
lock sequence targeting it.
Changed perf lock shows sequence of locks in time order,
and I grepped the output of it with dcache, like this:

% sudo ./perf lock report | grep dcache

The head part of result is this:
# <name>-<pid> <time (in u64)> <action> <address of lockdep> <name of lock>
perf-3238 92430534170 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92430536714 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92431444481 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92431446061 acquired: 0xffffffff81a4b398 dcache_lock
perf-3238 92431448157 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92431449670 acquired: 0xffffffff81a4b398 dcache_lock
perf-3238 92432371136 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92432372712 acquired: 0xffffffff81a4b398 dcache_lock
perf-3238 92432374718 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92432376173 acquired: 0xffffffff81a4b398 dcache_lock
perf-3238 92433315563 acquire: 0xffffffff81a4b398 dcache_lock
perf-3238 92433317173 acquired: 0xffffffff81a4b398 dcache_lock

There are too many acquire and acquired without corresponding release
(or contended).
If dcache_lock is rwlock and these acquires mean read locks, this is not
so strange.
But, for me, this is a pattern of dead lock.
Of course perf lock finished its work, so there is no actual dead lock.

If you know something about this behaviour of lock, could you tell me?

Thanks,
	Hitoshi

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