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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxZ7yj7Jdt1H9JQJNQUgZSLft_b=rAZv0tw95tjQ0Eq2A@mail.gmail.com>
Date:	Sun, 4 Jan 2015 11:46:30 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Dave Jones <davej@...emonkey.org.uk>,
	Thomas Gleixner <tglx@...utronix.de>, Chris Mason <clm@...com>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Dâniel Fraga <fragabr@...il.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Suresh Siddha <sbsiddha@...il.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Peter Anvin <hpa@...ux.intel.com>
Subject: Re: frequent lockups in 3.18rc4

On Fri, Jan 2, 2015 at 4:27 PM, John Stultz <john.stultz@...aro.org> wrote:
>
> So I sent out a first step validation check to warn us if we end up
> with idle periods that are larger then we expect.

.. not having tested it, this is just from reading the patch, but it
would *seem* that it doesn't actually validate the clock reading much
at all.

Why? Because most of the time, for crap clocks like HPET, the real
limitation will be not the multiplication overflow, but the "mask",
which is just 32-bit (or worse - I think the ACPI PM timer might be
just 24 bits).

So then you effectively "validate" that the timer difference value
fits in mask, but that isn't any validation at all - it's just a
truism. Since we by definition mask the difference to just the valid
bitmask.

So I really think that the maximum valid clock needs to be narrowed
down from the "technically, this clock can count to X".

But maybe I'm wrong, and the multiplication overflow is actually often
the real limit. What are the actual values for real timer sources?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ