linux-kernel - Re: [PATCHv2 4/6] sched_clock: Add support for >32 bit sched

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: <20130610153850.GU18614@n2100.arm.linux.org.uk>
Date:	Mon, 10 Jun 2013 16:38:50 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	anish singh <anish198519851985@...il.com>
Cc:	Stephen Boyd <sboyd@...eaurora.org>, linux-arm-msm@...r.kernel.org,
	Will Deacon <will.deacon@....com>,
	linux-kernel-mail <linux-kernel@...r.kernel.org>, arm@...nel.org,
	John Stultz <john.stultz@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCHv2 4/6] sched_clock: Add support for >32 bit sched_clock

On Mon, Jun 10, 2013 at 08:46:36PM +0530, anish singh wrote:
> Probably a trivial question.I was wondering why this particular requirement
> exists in the first place.I looked into this commit 112f38a4a3 but couldn't
> gather the reason.

You're looking at a commit introducing an implementation.  The requirement
isn't driven by the implementation.  It's driven by the code and the maths
in the core scheduler, and its been a requirement for years.

sched_clock() needs to be monotonic, and needs to wrap at 64-bit, because
calculations are done by comparing the difference of two 64-bit values
returned from this function.

Let's take a trivial example - if you have a 16 bit counter, and you have
a value of 0xc000 ns, and next time you read it, it has value 0x0001 ns,
then what value do you end up with when you calculate the time passed
using 64-bit maths.

That's 0x0000000000000001 - 0x000000000000c000.  The answer is a very big
number which is not the correct 16385.  This means that things like process
timeslice counting and scheduler fairness is compromised - I'd expect even
more so if you're running RT and this is being used to provide guarantees.
--
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/