linux-stable.git/tools/lib/lockdep, branch linux-4.1.y Linux kernel stable tree tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth 2017-07-31T17:37:54+00:00 Ben Hutchings ben@decadent.org.uk 2017-05-25T12:58:33+00:00 4bae4fd1593bd212d9e6c3e27dda306da197eff7 [ Upstream commit 98dcea0cfd04e083ac74137ceb9a632604740e2d ] liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is within the range of lock_chain::depth and in liblockdep it is much too large. That should have resulted in a compiler error, but didn't because: - the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep so is assumed to be an (undeclared) function - putting a function call inside a BUILD_BUG_ON() expression quietly turns it into some nonsense involving a variable-length array It did produce a compiler warning, but I didn't notice because liblockdep already produces too many warnings if -Wall is enabled (which I'll fix shortly). Even before that commit, which reduced lock_chain::depth from 8 bits to 6, MAX_LOCK_DEPTH was too large. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Cc: <stable@vger.kernel.org> # for versions before 4.6, use a value of 255 Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: a.p.zijlstra@chello.nl Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
[ Upstream commit 98dcea0cfd04e083ac74137ceb9a632604740e2d ]

liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix
lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is
within the range of lock_chain::depth and in liblockdep it is much
too large.

That should have resulted in a compiler error, but didn't because:

- the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep
  so is assumed to be an (undeclared) function
- putting a function call inside a BUILD_BUG_ON() expression quietly
  turns it into some nonsense involving a variable-length array

It did produce a compiler warning, but I didn't notice because
liblockdep already produces too many warnings if -Wall is enabled
(which I'll fix shortly).

Even before that commit, which reduced lock_chain::depth from 8 bits
to 6, MAX_LOCK_DEPTH was too large.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: <stable@vger.kernel.org> # for versions before 4.6, use a value of 255
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
tools/liblockdep: Fix compilation error 2015-05-13T10:12:20+00:00 Eunbong Song eunb.song@samsung.com 2015-05-13T10:02:32+00:00 2480257fb17ba0fdaf62bc8c2406bd08d5e7f8f1 Recent changes to kernel/locking/lockdep.c broke the liblockdep build. Fix that. Signed-off-by: Eunbong Song <eunb.song@samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> 
Recent changes to kernel/locking/lockdep.c broke the liblockdep build. Fix
that.

Signed-off-by: Eunbong Song <eunb.song@samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
tools/liblockdep: Fix linker error in case of cross compile 2015-05-13T10:09:09+00:00 Eunbong Song eunb.song@samsung.com 2015-04-24T04:36:27+00:00 d1e40e592678b8955a8ed36bdeaf42929822302e If we try to cross compile liblockdep, even if we set the CROSS_COMPILE variable the linker error can occur because LD is not set with CROSS_COMPILE. This patch adds "LD" can be set automatically with CROSS_COMPILE variable so fixes linker error problem. Signed-off-by: Eunbong Song <eunb.song@samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> 
If we try to cross compile liblockdep, even if we set the CROSS_COMPILE variable
the linker error can occur because LD is not set with CROSS_COMPILE.
This patch adds "LD" can be set automatically with CROSS_COMPILE variable so
fixes linker error problem.

Signed-off-by: Eunbong Song <eunb.song@samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Merge tag 'v4.0-rc1' into perf/core, to refresh the tree 2015-02-26T11:24:50+00:00 Ingo Molnar mingo@kernel.org 2015-02-26T11:24:50+00:00 e9e4e44309f866b115d08ab4a54834008c50a8a4 Signed-off-by: Ingo Molnar <mingo@kernel.org> 
Signed-off-by: Ingo Molnar <mingo@kernel.org>
tools lib lockdep: Use tools build framework 2015-02-12T20:56:01+00:00 Jiri Olsa jolsa@kernel.org 2015-01-09T16:11:04+00:00 9244e2c673fb148abb7706e47b602d009c537c9b Move the lockdep library building under tools build framework. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexis Berlemont <alexis.berlemont@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: S. Lockwood-Childs <sjl@vctlabs.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-i0t25buqyo5jfvzpw2347h1h@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 
Move the lockdep library building under tools build framework.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexis Berlemont <alexis.berlemont@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: S. Lockwood-Childs <sjl@vctlabs.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-i0t25buqyo5jfvzpw2347h1h@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
tools/liblockdep: don't include host headers 2015-01-30T02:55:19+00:00 Baruch Siach baruch@tkos.co.il 2015-01-25T13:30:23+00:00 8baeccdcb8e51bfb0f3349fc8f90abe8d5654f9e Adding host headers to include path may cause unexpected surprises when cross compiling. Remove /usr/local/include from the default include path. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> 
Adding host headers to include path may cause unexpected surprises when cross
compiling. Remove /usr/local/include from the default include path.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
tools/liblockdep: ignore generated .so file 2015-01-30T02:55:19+00:00 Baruch Siach baruch@tkos.co.il 2015-01-25T13:30:22+00:00 7728b352b78986dd8b0859e213fd59f5e37e4b8e Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> 
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
tools/liblockdep: Fix debug_check thinko in mutex destroy 2014-12-19T20:50:55+00:00 Kirill Smelkov kirr@nexedi.com 2014-12-08T11:07:59+00:00 95bfdf23e4d59099340c01064f39e7f6875c02bc In mutex destroy code currently we pass to debug_check_no_locks_freed() [mem_from, mem_end) address region. But debug_check_no_locks_freed() accepts mem_from, mem_*len* i.e. second parameter is region length, not end address. And it was always so, starting from 2006 (fbb9ce95 "lockdep: core"). Fix it, or else on a mutex destroy we wrongly check much-wider-than-mutex region and can find not-yet-released other locks there and wrongly report BUGs on them. Signed-off-by: Kirill Smelkov <kirr@nexedi.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> 
In mutex destroy code currently we pass to debug_check_no_locks_freed()

    [mem_from, mem_end)

address region. But debug_check_no_locks_freed() accepts

    mem_from, mem_*len*

i.e. second parameter is region length, not end address. And it was
always so, starting from 2006 (fbb9ce95 "lockdep: core").

Fix it, or else on a mutex destroy we wrongly check
much-wider-than-mutex region and can find not-yet-released other locks
there and wrongly report BUGs on them.

Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
tools/liblockdep: Account for bitfield changes in lockdeps lock_acquire 2014-07-07T16:20:16+00:00 S. Lockwood-Childs sjl@dent.vctlabs.com 2014-07-07T07:17:33+00:00 b10827814e9c81c5a14fb73c5a6e06bd85df3f94 Commit fb9edbe984 shortened held_lock->check from a 2-bit field to a 1-bit field. Make liblockdep compatible with the new definition by passing check=1 to lock_acquire() calls, rather than the old value check=2 (which inadvertently disabled checks by overflowing to 0). Without this fix, several of the test cases in liblockdep run_tests.sh were failing. Signed-off-by: S. Lockwood-Childs <sjl@vctlabs.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> 
Commit fb9edbe984 shortened held_lock->check from a 2-bit field
to a 1-bit field.

Make liblockdep compatible with the new definition by passing check=1
to lock_acquire() calls, rather than the old value check=2 (which
inadvertently disabled checks by overflowing to 0).

Without this fix, several of the test cases in liblockdep run_tests.sh
were failing.

Signed-off-by: S. Lockwood-Childs <sjl@vctlabs.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
tools/liblockdep: Remove debug print left over from development 2014-07-07T16:14:27+00:00 Sasha Levin sasha.levin@oracle.com 2014-07-07T16:14:27+00:00 0c37c686b336aeead2f0b982f24eafaeb19435b1 Remove a debug print in init_preload() which was left over from development and isn't usefull at all currently. It was also causing false positive test results. Reported-by: S. Lockwood-Childs <sjl@vctlabs.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> 
Remove a debug print in init_preload() which was left over from
development and isn't usefull at all currently. It was also causing
false positive test results.

Reported-by: S. Lockwood-Childs <sjl@vctlabs.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>