linux-kernel - Re: [BUG?] false positive in soft lockup detector while unlzma initramfs on slow cpu

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: <1359479907.1641.161.camel@anish-Inspiron-N5050>
Date:	Tue, 29 Jan 2013 22:48:27 +0530
From:	anish kumar <anish198519851985@...il.com>
To:	Don Zickus <dzickus@...hat.com>
Cc:	Mike Lykov <combr@...dex.ru>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org,
	kirill@...temov.name
Subject: Re: [BUG?] false positive in soft lockup detector while unlzma
 initramfs on slow cpu

On Tue, 2013-01-29 at 10:33 -0500, Don Zickus wrote:
> Hi Mike,
> 
> On Tue, Jan 29, 2013 at 05:42:43PM +0400, Mike Lykov wrote:
> > 
> > So my questions:
> > 
> > 1. Are there a BUG in soft lockup detection mechanizm? Changing
> > watchdog_thresh to 30 have a side effect in production - D-state
> > userspace processes will be detected slowly. Are there a need to
> > detecting soft lockups at boot time? Maybe it need after initramfs
you want to disable it then you can do that with nosoftlockup parameter
in kernel-parameters.
> > boot only when userspace processes begin to work?
If my understanding is correct you can do this as well by enabling
watchdog using sysctl.
> 
> The softlockup mechanism works scheduling a high priority task that kicks
> the softlockups.  If the unzip thread is taking too long, it could
> accidentally trip the detection.
> 
> Seeing that you are running on a 600 MHz machine, it could be possible.
> Though I am not entirely sure how the scheduling works for decompressing
> the initramfs.  I wouldn't think it is that high of a priority.
> 
> > 
> > 2. How to change watchdog_thresh parameter at boot without patching
> > sources? If it necessary (with it side effects) maybe implement it
> > as commandline parameter or config compile time parameter?
> 
> I attached a patch below that allows you to set it a boot time.  Let me
> know if this works for you, then I can clean it up and post it properly.
> 
> Cheers,
> Don
> 
> 
> diff --git a/kernel/watchdog.c b/kernel/watchdog.c
> index 75a2ab3..e448d63 100644
> --- a/kernel/watchdog.c
> +++ b/kernel/watchdog.c
> @@ -79,6 +79,14 @@ static int __init softlockup_panic_setup(char *str)
>  }
>  __setup("softlockup_panic=", softlockup_panic_setup);
>  
> +static int __init watchdog_thresh_setup(char *str)
> +{
> +	watchdog_thresh = simple_strtoul(str, NULL, 0);
> +
> +	return 1;
> +}
> +__setup("watchdog_thresh=", watchdog_thresh_setup);
> +
>  static int __init nowatchdog_setup(char *str)
>  {
>  	watchdog_enabled = 0;
Sorry for digressing from the topic but I think there is something wrong
with my understanding or something wrong with the code.So I guess Don
can clarify this.
If I pass this below parameter during boot i.e. setting watchdog_enabled
to zero.
__setup("nowatchdog", nowatchdog_setup);

Now I use sysctl to enable the watchdog then wouldn't the below code
will hinder enabling the watchdog?

static void watchdog_enable_all_cpus(void)
{//snip
        if (watchdog_disabled) {  /* this is zero ?? */
                watchdog_disabled = 0;
//snip
}

Should watchdog_disabled be set to 1?Or is it that we always disable the
watchdog and then enable it?

This code is used from long time and that is the reason I am puzzled as
to how it can be wrong?I think there is some missing piece which I am
not understanding.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/