• Peter Zijlstra's avatar
    locking/lockdep: Fix stacktrace mess · 8b405d5c
    Peter Zijlstra authored
    There is some complication between check_prevs_add() and
    check_prev_add() wrt. saving stack traces. The problem is that we want
    to be frugal with saving stack traces, since it consumes static
    We'll only know in check_prev_add() if we need the trace, but we can
    call into it multiple times. So we want to do on-demand and re-use.
    A further complication is that check_prev_add() can drop graph_lock
    and mess with our static resources.
    In any case, the current state; after commit:
      ce07a941 ("locking/lockdep: Make check_prev_add() able to handle external stack_trace")
    is that we'll assume the trace contains valid data once
    check_prev_add() returns '2'. However, as noted by Josh, this is
    false, check_prev_add() can return '2' before having saved a trace,
    this then result in the possibility of using uninitialized data.
    Testing, as reported by Wu, shows a NULL deref.
    So simplify.
    Since the graph_lock() thing is a debug path that hasn't
    really been used in a long while, take it out back and avoid the
    Further initialize the stack_trace to a known 'empty' state; as long
    as nr_entries == 0, nothing should deref entries. We can then use the
    'entries == NULL' test for a valid trace / on-demand saving.
    Analyzed-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
    Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Byungchul Park <byungchul.park@lge.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: ce07a941 ("locking/lockdep: Make check_prev_add() able to handle external stack_trace")
    Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
lockdep.c 126 KB