[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1466398527-1122-1-git-send-email-byungchul.park@lge.com>
Date: Mon, 20 Jun 2016 13:55:15 +0900
From: Byungchul Park <byungchul.park@....com>
To: peterz@...radead.org, mingo@...nel.org
Cc: linux-kernel@...r.kernel.org, npiggin@...e.de, walken@...gle.com,
ak@...e.de, tglx@...elltoy.tec.linutronix.de
Subject: [RFC 00/12] lockdep: Implement crossrelease feature
Crossrelease feature calls a lock which is releasable by a
different context from the context having acquired the lock,
crosslock. For crosslock, all locks having been held in the
context unlocking the crosslock, until eventually the crosslock
will be unlocked, have dependency with the crosslock. That's a
key idea to implement crossrelease feature.
Crossrelease feature introduces 2 new data structures.
1. pend_lock (== plock)
This is for keeping locks waiting to commit those so
that an actual dependency chain is built, when commiting
a crosslock.
Every task_struct has an array of this pending lock to
keep those locks. These pending locks will be added
whenever lock_acquire() is called for normal(non-crosslock)
lock and will be flushed(committed) at proper time.
2. cross_lock (== xlock)
This keeps some additional data only for crosslock. There
is one cross_lock per one lockdep_map for crosslock.
lockdep_init_map_crosslock() should be used instead of
lockdep_init_map() to use the lock as a crosslock.
Acquiring and releasing sequence for crossrelease feature:
1. Acquire
All validation check is performed for all locks.
1) For non-crosslock (normal lock)
The hlock will be added not only to held_locks
of the current's task_struct, but also to
pend_lock array of the task_struct, so that
a dependency chain can be built with the lock
when doing commit.
2) For crosslock
The hlock will be added only to the cross_lock
of the lock's lockdep_map instead of held_locks,
so that a dependency chain can be built with
the lock when doing commit. And this lock is
added to the xlocks_head list.
2. Commit (only for crosslock)
This establishes a dependency chain between the lock
unlocking it now and all locks having held in the context
unlocking it since the lock was held, even though it tries
to avoid building a chain unnecessarily as far as possible.
3. Release
1) For non-crosslock (normal lock)
No change.
2) For crosslock
Just Remove the lock from xlocks_head list. Release
operation should be used with commit operation
together for crosslock, in order to build a
dependency chain properly.
Byungchul Park (12):
lockdep: Refactor lookup_chain_cache()
lockdep: Add a function building a chain between two hlocks
lockdep: Make check_prev_add can use a stack_trace of other context
lockdep: Make save_trace can copy from other stack_trace
lockdep: Implement crossrelease feature
lockdep: Apply crossrelease to completion
pagemap.h: Remove trailing white space
lockdep: Apply crossrelease to PG_locked lock
cifs/file.c: Remove trailing white space
mm/swap_state.c: Remove trailing white space
lockdep: Call lock_acquire(release) when accessing PG_locked manually
x86/dumpstack: Optimize save_stack_trace
arch/x86/include/asm/stacktrace.h | 1 +
arch/x86/kernel/dumpstack.c | 2 +
arch/x86/kernel/dumpstack_32.c | 2 +
arch/x86/kernel/stacktrace.c | 7 +
fs/cifs/file.c | 6 +-
include/linux/completion.h | 121 +++++-
include/linux/irqflags.h | 16 +-
include/linux/lockdep.h | 139 +++++++
include/linux/mm_types.h | 9 +
include/linux/pagemap.h | 104 ++++-
include/linux/sched.h | 5 +
kernel/fork.c | 4 +
kernel/locking/lockdep.c | 846 +++++++++++++++++++++++++++++++++++---
kernel/sched/completion.c | 55 +--
lib/Kconfig.debug | 30 ++
mm/filemap.c | 10 +-
mm/ksm.c | 1 +
mm/migrate.c | 1 +
mm/page_alloc.c | 3 +
mm/shmem.c | 2 +
mm/swap_state.c | 12 +-
mm/vmscan.c | 1 +
22 files changed, 1255 insertions(+), 122 deletions(-)
--
1.9.1
Powered by blists - more mailing lists