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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOFt0_AFnR0MF2e8rRXhz_wkiGbL2VTFy=AXpcmWTZ9_bYA=VQ@mail.gmail.com>
Date:	Wed, 28 Oct 2015 10:20:06 +0000
From:	Alex Smith <alex@...x-smith.me.uk>
To:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>,
	David Daney <ddaney.cavm@...il.com>
Cc:	Ralf Baechle <ralf@...ux-mips.org>,
	Markos Chandras <markos.chandras@...tec.com>,
	linux-mips <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 27 October 2015 at 20:46, Leonid Yegoshin <Leonid.Yegoshin@...tec.com> wrote:
> 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.

The VDSO code will currently use the CP0 count whenever the kernel is
using it as its primary clocksource, aside from the case where RDHWR
is broken as it is on old QEMUs.

Maybe I'm missing something but I don't see anything in the generic
timekeeping code that handles the same clocksource being
unsynchronised or running at a different rate on different CPUs.

Given that, if you think there is an issue that prevents the VDSO from
using it then that would surely affect the kernel as well and needs to
be fixed separately?

If it really is necessary to prevent the VDSO from using a certain
clocksource even though the kernel is using it, it should be a simple
matter of setting clocksource.archdata.vdso_clock_mode to
VDSO_CLOCK_NONE. This is how this patch stops it using the CP0 count
when RDHWR is broken.

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