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]
Date:   Mon, 27 Nov 2017 14:36:52 -0500
From:   Waiman Long <>
To:     Yang Shi <>,
Subject: Re: [RFC PATCH 2/2] lib: debugobjects: touch watchdog to avoid
 softlockup when !CONFIG_PREEMPT

On 11/27/2017 01:52 PM, Yang Shi wrote:
> On 11/27/17 10:18 AM, Waiman Long wrote:
>> On 11/27/2017 12:54 PM, Yang Shi wrote:
>>> Hi Waiman,
>>> The second patch of this series.
>>> Thanks,
>>> Yang
>>> On 11/17/17 11:43 AM, Yang Shi wrote:
>>>> There are nested loops on debug objects free path, sometimes it may
>>>> take
>>>> over hundred thousands of loops, then cause soft lockup with
>>>> occasionally, like below:
>>>>   ...
>>>> The code path might be called in either atomic or non-atomic context,
>>>> so touching softlockup watchdog instead of calling cond_resched()
>>>> which
>>>> might fall asleep. However, it is unnecessary to touch the watchdog
>>>> every loop, so just touch the watchdog at every 10000 (best estimate)
>>>> loops.
>>>> Signed-off-by: Yang Shi <>
>> I do have some concern about suppressing the soft lockup warning
>> entirely. If the system feels unresponsive for a certain period of time
>> (e.g. 22s), most users would like to know what is going on. It can be a
>> custom message with less scary warning. Alternatively, some opt-out
> I'm not sure if it is necessary for debug code since the
> unresponsiveness is introduced by debug config and is expected
> somehow, so the user is supposed to know what they are doing, and it
> sounds preferred to disregard the soft lockup message reported by
> object debug for the most time.

Yes, it may be normal to cause the soft lockup while running some kind
of stress tests. However, it isn't normal for a real user application to
cause the lockup on a debug kernel. That is why I am suggesting some
kind of opt-out mechanism so that one can turn off the soft lockup
warning for stress testing.

> We do have some other examples which suppress soft lockup completely
> in kernel, i.e. kdb debug, printing some verbose debug or error
> message, some slow driver code, etc.
>> mechanism can be added to explicitly disable soft lookup warning for
>> debugobjs is OK as long as it is not the default.
> If we really want to some opt-out, we should be able to add a proc
> knob to disable soft lockup as the patch does, but not default. If
> this is too overkilling, we may just add some comment in the Kconfig
> help text to tell users the side effect. 

You may add a new debugfs file under the debug_objects sub-directory for
suppressing the soft lockup message.


Powered by blists - more mailing lists