linux-kernel - Re: [PATCH] hung_task: recover hung task warnings in next check interval

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] [day] [month] [year] [list]

Date:   Thu, 20 Jun 2019 18:47:34 +0800
From:   Yafang Shao <laoar.shao@...il.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] hung_task: recover hung task warnings in next check interval

On Thu, Jun 20, 2019 at 6:23 PM Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
>
> On 2019/06/20 19:10, Yafang Shao wrote:
> >>> With this patch, hung task warnings will be reset with
> >>> sys_hung_task_warnings setting in evenry check interval.
> >>
> >> Since it is uncommon that the messages are printed for more than 10
> >> times for one check_hung_uninterruptible_tasks() call, this patch is
> >> effectively changing to always print the messages (in other words,
> >> setting -1).
> >
> > If sys_hung_task_warnings can't be recovered, does it make sense to exist?
> > In which case do we need this setting ?
>
> Someone might want to print the messages up to only a few times because he/she
> does not like the ever-repeating messages.

But some new difference hung task information may be missed.
And the reason of the new hung task may be different with the old one.

So I still can't understand it.

It would be better if you could give some use cases in the real world.

> But automatically resetting will
> forbid his/her wish to print the messages for up to only a few times.
>
> >
> > Btw, why the default value of this setting is 10, instead of -1 ?
>
> I don't know. I guess just by historical reason, for this variable
> has been existed before support of -1 is added.
>

I think we'd better change the default value from 10 to -1,
because this is the common use case.
And then the user don't need to write it into sysctl.conf again.

Thanks
Yafang