linux-kernel - Re: [PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes

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] [day] [month] [year] [list]

Message-ID: <51BF8BE6.5080704@codeaurora.org>
Date:	Mon, 17 Jun 2013 15:21:26 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	John Stultz <john.stultz@...aro.org>
CC:	Russell King <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes

On 06/17/13 14:50, John Stultz wrote:
> On 06/17/2013 12:51 PM, Stephen Boyd wrote:
>> John,
>>
>> I just saw your pull request for making this code generic. I believe
>> this patch fixes a bug that nobody has seen in practice so it's probably
>> fine to delay this until 3.11.
>>
>> Also, I've just noticed that "ARM: sched_clock: Return suspended count
>> earlier" that I sent in that series is going to break the arm
>> architected timer path because they're circumventing all this epoch_ns
>> code. It would be better if you could replace that patch with this patch
>> because this optimizes it in the same way and also fixes a bug at the
>> same time.
>
> Sorry, could you clarify a bit more? The above sounds like there are
> two issues, but you only sent one patch.

I'm saying that the "return the suspended count earlier" patch is bad.
But this patch does what that patch is doing plus it fixes a race at the
same time. So it would be better to just take this patch and drop the other.

The problem is that when the cd.suspended flag is true we're going to
return the jiffies based sched_clock value for the ARM architected timer
driver (the only driver that replaces the sched_clock_func function
pointer with its own function). Jiffies should be pretty close to the
actual time anyway, but since the ARM architected timer driver is
already broken with respect to suspend (because it doesn't stop the
sched_clock value from incrementing during suspend) it doesn't really
matter. Every other driver using the sched_clock code will not be
affected either way.

>
> I'm also not sure how to proceed with the patch you sent, since it
> collides with the patch that moves sched_clock to be generic.

Ah I thought that the git rename detection would just make it work.

>
> Could you refactor the change on-top of git branch I sent to Thomas?
> Otherwise I'll have to withdraw the pull request, and we'll probably
> miss 3.11 for the generic sched_clock change.

Sure. I'll send it right now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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