linux-kernel - Re: [PATCH v2] hungtask: add filter kthread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YRDyquuwshpHNdz0@dhcp22.suse.cz>
Date:   Mon, 9 Aug 2021 11:17:30 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     chenguanyou <chenguanyou9338@...il.com>
Cc:     akpm@...ux-foundation.org, chenguanyou@...omi.com,
        gpiccoli@...onical.com, keescook@...omium.org,
        linux-kernel@...r.kernel.org, lukas.bulwahn@...il.com,
        vbabka@...e.cz
Subject: Re: [PATCH v2] hungtask: add filter kthread

On Sat 07-08-21 21:16:00, chenguanyou wrote:
> > Please explain this point in more detail?
> 
> In my work,the rootcause of more deadlocks often occurs in user threads.
> 
> exp:
> PID: 711 TASK: ffffffc13eb71d00 CPU: 0 COMMAND: "sensors@...-ser"
> #0 [ffffff80251cbcb0] __switch_to at ffffff80080866c4
> #1 [ffffff80251cbd20] __schedule at ffffff80090c0940
> #2 [ffffff80251cbd80] schedule_preempt_disabled at ffffff80090c0e4c
> #3 [ffffff80251cbde0] __mutex_lock at ffffff80090c2e58
> #4 [ffffff80251cbe40] __mutex_lock_slowpath at ffffff80090c1f78
> #5 [ffffff80251cbe50] mutex_lock at ffffff80090c1f60
> #6 [ffffff80251cbe60] __fdget_pos at ffffff800829ac84
> #7 [ffffff80251cbe90] sys_write at ffffff8008270550
> #8 [ffffff80251cbff0] el0_svc_naked at ffffff8008083fbc
> 
> PID: 843 TASK: ffffffc135832b80 CPU: 2 COMMAND: "sensors@...-ser"
> #0 [ffffff802554bb30] __switch_to at ffffff80080866c4
> #1 [ffffff802554bba0] __schedule at ffffff80090c0940
> #2 [ffffff802554bc00] schedule at ffffff80090c0d54
> #3 [ffffff802554bc50] xxx_sensor_show at ffffff8008bc043c
> #4 [ffffff802554bc80] dev_attr_show at ffffff8008668ce0
> #5 [ffffff802554bca0] sysfs_kf_seq_show at ffffff8008314e04
> #6 [ffffff802554bce0] kernfs_seq_show at ffffff8008314314
> #7 [ffffff802554bd10] seq_read at ffffff80082a250c
> #8 [ffffff802554bd70] kernfs_fop_read at ffffff80083135b8
> #9 [ffffff802554be20] __vfs_read at ffffff800826fcc0
> #10 [ffffff802554be40] vfs_read at ffffff800826ff08
> #11 [ffffff802554be90] sys_read at ffffff80082704c4
> #12 [ffffff802554bff0] el0_svc_naked at ffffff8008083fbc
> 
> The rootcause is deadlock caused by using same fd, and 843's file ops is block type;
> If we want to trigger panic in the first time through hungtask,
> must be avoid detect kernel threads on some platforms("mediatek"),
> because they("kernel threads") cause misjudgments.

This still suggests that the primary purpose of the interface is to
paper over real problems that should be fixed instead.
-- 
Michal Hocko
SUSE Labs