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]

Date:	Mon, 10 Jun 2013 21:31:21 +0530
From:	anish singh <anish198519851985@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
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 9:08 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:

Least I can do is to say "Thanks".
> 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.

Yes, and this is the question.If it is 32 bit then also it can overflow but
it will happen relatively fast.So I guess that is the reason why we use 64 bit
and this will avoid recalculations for recalibration.
>
> 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

So you mean when counter overflows the scheduler doesn't handle it?
> 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/