linux-kernel - Re: PPro arch_cpu_idle: NMI watchdog: Watchdog detected hard LOCKUP on cpu 1

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:   Mon, 6 Mar 2017 13:42:04 +0200 (EET)
From:   Meelis Roos <mroos@...ux.ee>
To:     Frederic Weisbecker <fweisbec@...il.com>
cc:     Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel list <linux-kernel@...r.kernel.org>,
        x86@...nel.org, Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: PPro arch_cpu_idle: NMI watchdog: Watchdog detected hard LOCKUP
 on cpu 1

> On Sun, Mar 05, 2017 at 10:48:50PM +0200, Meelis Roos wrote:
> > Added some CC-s because of bisect find. Whole context should be still 
> > here.
> > 
> > > > > > > > This is on my trusty IBM PC365, dual Pentium Pro. 4.10 worked fine, 
> > > > > > > > 4.10.0-09686-g9e314890292c and 4.10.0-10770-g2d6be4abf514 exhibit a 
> > > > > > > > problem. Ocassionally NMI watchdog kicks in and discovers one of the 
> > > > > > > > CPUs in LOCKUP. The system keeps running fine. The first lockup was 
> > > > > > > > different, all the others were from arch_cpu_idle. Sometime ecey couple 
> > > > > > > > of seconds (after some activity), sometimes nothing for a long time 
> > > > > > > > (idle, no SSH logins).
> > > > > > > 
> > > > > > > The only watchdog related patch which hit after 4.10 is:
> > > > > > > 
> > > > > > >  8dcde9def5a1 kernel/watchdog.c: do not hardcode CPU 0 as the initial thread
> > > > > > > 
> > > > > > > Can you try to revert that for a start? I'm not seeing why it should be the
> > > > > > > culprit from a quick glance, but ...
> > > > > > 
> > > > > > Reverting this patch does not help.
> > > > > 
> > > > > I did not expect that, but excluding it was a valid shot in the
> > > > > dark. Thanmks for trying.
> > > > > 
> > > > > To be honest, I have no idea what causes that at the moment, but I will
> > > > > come back to you tomorrow after thinking it through (with brain awake) how
> > > > > to debug this.
> > > > 
> > > > Went through the related changes which came in during the merge window. One
> > > > which affects the per cpu timers is: 914122c389d0
> > > > 
> > > > Can you try to revert that one please?
> > > 
> > > Running out of obvious culprits. Any chance that you can do a bisect or
> > > this too painful on that box?
> > 
> > Done on a P4 where the problem also appeared. The bisecting resulted in 
> > this commit. Does it seem realistic? I will also try if this help son 
> > the old PPro.
> > 
> > 93825f2ec736f30e034ab7c9d56b42849c5b00da is the first bad commit
> > commit 93825f2ec736f30e034ab7c9d56b42849c5b00da
> > Author: Frederic Weisbecker <fweisbec@...il.com>
> > Date:   Tue Jan 31 04:09:16 2017 +0100
> > 
> >     jiffies: Reuse TICK_NSEC instead of NSEC_PER_JIFFY

[...]
> Ouch, looking at that patch again, I probably had a delusional moment when I wrote this:
> 
> diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
> index a4a0e47..7906b3f 100644
> --- a/kernel/time/jiffies.c
> +++ b/kernel/time/jiffies.c
> @@ -125,7 +125,7 @@ int register_refined_jiffies(long cycles_per_second)
>  	shift_hz += cycles_per_tick/2;
>  	do_div(shift_hz, cycles_per_tick);
>  	/* Calculate nsec_per_tick using shift_hz */
> -	nsec_per_tick = (u64)NSEC_PER_SEC << 8;
> +	nsec_per_tick = (u64)TICK_NSEC << 8;
>  	nsec_per_tick += (u32)shift_hz/2;
>  	do_div(nsec_per_tick, (u32)shift_hz);
>  
> 
> 
> Could you please retry after reverting this specific chunk? (that would be the very fix
> to apply).

Reverting this chunk fixed both the PPro and the P4.

-- 
Meelis Roos (mroos@...ux.ee)