linux-kernel - Re: [PATCH] RFC: hung task: Check specific tasks for long uninterruptible sleep state

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: <b65cf7ff-8834-879a-bb51-5ad8e6f20126@codeaurora.org>
Date:   Wed, 23 Aug 2017 17:55:46 +0530
From:   Imran Khan <kimran@...eaurora.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     mingo@...nel.org, imrank140517@...il.com,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Shile Zhang <shile.zhang@...ia.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vegard Nossum <vegard.nossum@...cle.com>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        John Siddle <jsiddle@...hat.com>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:PROC SYSCTL" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] RFC: hung task: Check specific tasks for long
 uninterruptible sleep state

On 8/23/2017 2:06 AM, Peter Zijlstra wrote:
> On Mon, Aug 21, 2017 at 03:55:53PM +0530, Imran Khan wrote:
>> khungtask by default monitors either all tasks or no tasks at all
>> for long unterruptible sleeps.
>> For Android like environments this arrangement is not optimal because
>> on one hand it may be permissible to have some background(bg) task
>> in uninterruptible sleep state for long duration while on the other
>> hand it may not be permissible to have some foreground(fg) task like
>> surfaceflinger in uninterruptible sleep state for long duration.
> 
> How are you getting tasks in UNINTERRUPTIBLE state for a long time to
> begin with? That's not a good thing, background or not.
> 
As of now, I don't have the details of exact test case as most of these issues are
coming in android aging and stress tests but I see even in a non-android
setup I get few tasks in uninterruptible sleep state for long duration (60 secs).
For example, I see there is a thread waiting for mmc requests to appear from block
layer. Of course this can be a faulty design on the driver side too but my main
intention here is to know if we can enable/disable this monitoring for 
specific tasks and whether such an option would be useful and agreeable to
community or not.

Also in current scheme of things we use same timeout for all tasks which may
not be optimal. For example if some task is in disk sleep state it may be okay
for it to wait for 2 minutes but if surfaceflinger (android) is stuck even for
1 minute, it results in a very poor UI experience for user of the phone.
>> So it would be good to have some arrangement so that few specified tasks
>> can be monitored by khungtaskd, on a need basis.
>> This change introduces a sysctl option, /proc/sys/kernel/
>> hung_task_check_selected, to enable monitoring of selected tasks using
>> khungtask daemon. If this sysctl option is enabled then only the tasks
>> specified in /proc/hung_task_monitor_list are monitored otherwise all
>> tasks are monitored, just like the default case.
> 
> That's horrible. Why not a file in /proc/$PID/ that excludes it from
> things?
> 
To be honest, I also had apprehension about my approach and did not think
it through. I agree that /proc/$PID/ based approach is much better. If it is
agreed that selective monitoring of hung tasks has valid use case(s), I can
send the /proc/$PID based patch for review.
Thanks for your time and feedback.

Regards,
Imran


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation