lkml.org 
[lkml]   [2023]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v3] locking/lockdep: add debug_show_all_lock_holders()
    From
    Ingo or Peter, are you there?

    Linus is expecting that this patch (if acceptable) is sent from the locking people.

    https://lkml.kernel.org/r/CAHk-=wjbu9USn=hVWQ9v9t1H+8R6qXj8REkm36==w10zM0cM6g@mail.gmail.com

    On 2023/02/02 22:59, Tetsuo Handa wrote:
    > Currently, check_hung_uninterruptible_tasks() reports details of locks
    > held in the system. Also, lockdep_print_held_locks() does not report
    > details of locks held by a thread if that thread is in TASK_RUNNING state.
    > Several years of experience of debugging without vmcore tells me that
    > these limitations have been a barrier for understanding what went wrong
    > in syzbot's "INFO: task hung in" reports.
    >
    > I initially thought that the cause of "INFO: task hung in" reports is
    > due to over-stressing. But I understood that over-stressing is unlikely.
    > I now consider that there likely is a deadlock/livelock bug where lockdep
    > cannot report as a deadlock when "INFO: task hung in" is reported.
    >
    > A typical case is that thread-1 is waiting for something to happen (e.g.
    > wait_event_*()) with a lock held. When thread-2 tries to hold that lock
    > using e.g. mutex_lock(), check_hung_uninterruptible_tasks() reports that
    > thread-2 is hung and thread-1 is holding a lock which thread-2 is trying
    > to hold. But currently check_hung_uninterruptible_tasks() cannot report
    > the exact location of thread-1 which gives us an important hint for
    > understanding why thread-1 is holding that lock for so long period.
    >
    > When check_hung_uninterruptible_tasks() reports a thread waiting for a
    > lock, it is important to report backtrace of threads which already held
    > that lock. Therefore, allow check_hung_uninterruptible_tasks() to report
    > the exact location of threads which is holding any lock.
    >
    > debug_show_all_lock_holders() skips current thread if the caller is
    > holding no lock, for reporting RCU lock taken inside that function is
    > generally useless.
    >
    > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    > ---
    > Changes in v3:
    > Unshare debug_show_all_lock_holders() and debug_show_all_locks(),
    > suggested by Ingo Molnar <mingo@kernel.org>.
    >
    > Changes in v2:
    > Share debug_show_all_lock_holders() and debug_show_all_locks(),
    > suggested by Waiman Long <longman@redhat.com>.
    >
    > include/linux/debug_locks.h | 5 +++++
    > kernel/hung_task.c | 2 +-
    > kernel/locking/lockdep.c | 28 ++++++++++++++++++++++++++++
    > 3 files changed, 34 insertions(+), 1 deletion(-)
    >

    \
     
     \ /
      Last update: 2023-03-27 00:19    [W:8.129 / U:1.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site