linux-kernel - Re: [PATCH 19/21] clocksource: Improve comment explaining clocks_calc_max

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: <20150402183447.GC27490@worktop.programming.kicks-ass.net>
Date:	Thu, 2 Apr 2015 20:34:47 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	John Stultz <john.stultz@...aro.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Prarit Bhargava <prarit@...hat.com>,
	Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH 19/21] clocksource: Improve comment explaining
 clocks_calc_max_nsecs()'s 50% safety margin

On Thu, Apr 02, 2015 at 10:30:18AM -0700, John Stultz wrote:
> > Should we make a further note that the tk_fast things rely on this
> > slack since they're not strongly serialized against this? That is, they
> > can end up using an older cycle_last value and therefore end up with a
> > larger delta than other code.
> 
> Though, even with the tk_fast bits, we expect the update to happen
> regularly, its just that for the benefit of lock-free access we are ok
> with the possible slight inconsistencies (in the mono clock) that
> could happen if we use a slightly stale value mid-update. So I don't
> think the tk_fast bits are actually relying on the slack any more then
> the normal timekeeping code relies on the slack to handle slight
> delays in processing the updates.  If we deal with time deltas large
> enough to cause overflows, or time intervals larger then the hardware
> can represent, we're sunk in either case. This 50% margin just makes
> it easier to catch unexpected delays or issues.

Right, so you're saying that even though the fast bits will see slightly
larger deltas than the normal code, they should still not get anywhere
near the 50% because we update much more frequently?
--
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/