From bdfc7670772b613fd810b9ec89b0af91e748ef80 Mon Sep 17 00:00:00 2001 From: Vladislav Bolkhovitin Date: Wed, 21 Dec 2016 03:39:24 +0000 Subject: [PATCH] scst: document nolockdep patches git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@7078 d57e44dd-8a1f-0410-8b47-8ef2f437770f --- scst/kernel/README_nolockdep | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 scst/kernel/README_nolockdep diff --git a/scst/kernel/README_nolockdep b/scst/kernel/README_nolockdep new file mode 100644 index 000000000..0ecc0fe03 --- /dev/null +++ b/scst/kernel/README_nolockdep @@ -0,0 +1,17 @@ +In some cases SCST needs to take multiple locks recursivly, e.g. to lock +all tgt_devs in a session. For this case SCST takes those locks in their +current sort order, e.g. by LUN for tgt_devs, then releases in the +opposite order. Unfortunately, lockdep complains on such actions as +recursive locking, then disables itself. The disabling itself action is +the most unpleasant one leading to lockdep being useless after this +point. + +Unfortunately, nested locking annotations can't help, because after +free, then alloc again, or after LUN change (in case of tgt_devs) order +of locks can change. + +So, SCST has a set of nolockdep-x.y patches together with "*_nolockdep" +locks to implement a way to annotate some lock and unlock actions as "no +lockdep", so lockdep will not track them. + +This is a debug aid useful only with lockdep enabled kernels.