linux-kernel - Re: NMI watchdog + NOHZ question

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: <20090622.022752.219499742.davem@davemloft.net>
Date:	Mon, 22 Jun 2009 02:27:52 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	andi@...stfloor.org
Cc:	linux-kernel@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: NMI watchdog + NOHZ question

From: Andi Kleen <andi@...stfloor.org>
Date: Mon, 22 Jun 2009 10:18:50 +0200

> David Miller <davem@...emloft.net> writes:
>>
>> Is there something fundamental that should be preventing this?
> 
> Unless that changed recently when I wasn't looking NOHZ should only
> stop timers when the CPU is idle. So when a driver is doing
> something and the interrupts are not disabled for too long the timers
> should be ticking.
> 
> Then when you're idle interrupts should be never off, so the NMI
> watchdog cannot fire. On x86 often the NMI watchdog is in fact
> stopped on idle.

Thanks Andi.

I think something else is afoot, because while using "nohz=off" makes
the problem go away, simply adding a NMI watchdog touch after the
schedule() call in cpu_idle() does not make the problem go away.

Also, the cpu that gets the NMI watchdog is different from the cpu
running the qla2xxx driver init.   That basically destroys the bulk
of my theory :-)
--
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/