linux-kernel - Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock

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]

Date:	Tue, 27 Oct 2015 13:46:20 -0700
From:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
To:	Ralf Baechle <ralf@...ux-mips.org>
CC:	Markos Chandras <markos.chandras@...tec.com>,
	<linux-mips@...ux-mips.org>, Alex Smith <alex.smith@...tec.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and
 clock_gettime()

On 10/27/2015 07:47 AM, Ralf Baechle wrote:
> On Thu, Oct 22, 2015 at 06:41:30PM -0700, Leonid Yegoshin wrote:
>
>> You can not use R4K CP0_count in SMP (multicore) without core-specific
>> adjustment.
>> After first power-saving with core clock off or core down the values in
>> CP0_count
>> in different cores are absolutely different.
>>
>> Until you include in system a patch like
>> http://patchwork.linux-mips.org/patch/10871/
>>
>>      "MIPS: Setup an instruction emulation in VDSO protected page instead of
>> user stack"
>>
>> which creates a per-thread memory and put into that memory an adjustment
>> value
>> (which can be changed during re-schedule to another core), the use of R4K
>> counter is incorrect
>> in SMP environment.
>>
>> Note: It is also possible to setup and maintain a per-core page with that
>> value too as
>> an alternative variant for adjustment.
> The CPU hot plugging code is supposed to resychronize the counters when
> a CPU is coming online again so that case should be handled.  Beyond that
> the r4k timer code in the kernel also doesn't support clock scaling
> so I'm ok if the VDSO series doesn't support this properly.
>
>    Ralf

I doesn't work in this way - a standard CP0_counter synchronization code 
takes up to hundred milliseconds to complete with running some loop 
cycles on two CPUs. It is clearly seen in Malta FPGA board.

Non-standard (one way sync, write CP0_counter value to memory in CPU0 
before CPU1 wakeup) is not precise because it can't predict how much 
time the CPU1 can spent in wakeup. Just because of HW, for exam, and SW 
next.

I believe, until this issue is fixed the R4K only CPU should be excluded 
from VDSO timing acceleration.

And finally. clock scaling - what we would do if there are two CPUs with 
different clock ratios in system? It seems like common kernel timing 
subsystem can handle that.

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