linux-kernel - Re: [PATCH 8/9] clocksource: Improve unstable clocksource detection

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]

Date:	Tue, 18 Aug 2015 10:57:50 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Shaohua Li <shli@...com>
cc:	John Stultz <john.stultz@...aro.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Prarit Bhargava <prarit@...hat.com>,
	Richard Cochran <richardcochran@...il.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 8/9] clocksource: Improve unstable clocksource
 detection

On Mon, 17 Aug 2015, Shaohua Li wrote:
> On Mon, Aug 17, 2015 at 03:17:28PM -0700, John Stultz wrote:
> > That said, I agree the "should"s and other vague qualifiers in the
> > commit description you point out should have more specifics to back
> > things up. And I'm fine delaying this (and the follow-on) patch until
> > those details are provided.
> 
> It's not something I guess. We do see the issue from time to time. The
> IPMI driver accesses some IO ports in softirq and hog cpu for a very
> long time, then the watchdog alert.

You still fail to provide proper numbers. 'very long time' does not
qualify as an argument at all.

> The false alert on the other hand has very worse effect. It forces
> to use HPET as clocksource, which has very big performance
> penality. We can't even manually switch back to TSC as current
> interface doesn't allow us to do it, then we can only reboot the
> system. I agree the driver should be fixed, but the watchdog has
> false alert, we definitively should fix it.

I tend to disagree. The watchdog has constraints and the driver is
violating these constraints, so the first thing which wants to be
addressed is the driver itself.

The behaviour of the watchdog in the case of constraint violations is
definitely suboptimal and can lead to false positives. I'm not against
making that more robust, but I'm not accepting your 'watchdog is
broken' argumentation at all.

Thanks,

	tglx
--
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/