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]
Message-ID: <CALCETrUd=16gAYvx93EsyMaaSJ-6mLvSru8Gie48Y+_dXq5FGA@mail.gmail.com>
Date: Sun, 31 Dec 2023 13:09:52 -0800
From: Andy Lutomirski <luto@...nel.org>
To: Sagi Maimon <maimon.sagi@...il.com>
Cc: richardcochran@...il.com, luto@...nel.org, datglx@...utronix.de, 
	mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org, 
	hpa@...or.com, arnd@...db.de, geert@...ux-m68k.org, peterz@...radead.org, 
	hannes@...xchg.org, sohil.mehta@...el.com, rick.p.edgecombe@...el.com, 
	nphamcs@...il.com, palmer@...ive.com, keescook@...omium.org, 
	legion@...nel.org, mark.rutland@....com, linux-kernel@...r.kernel.org, 
	linux-api@...r.kernel.org, linux-arch@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v4] posix-timers: add multi_clock_gettime system call

On Sun, Dec 31, 2023 at 9:07 AM Sagi Maimon <maimon.sagi@...il.com> wrote:
>
> Some user space applications need to read some clocks.
> Each read requires moving from user space to kernel space.
> The syscall overhead causes unpredictable delay between N clocks reads
> Removing this delay causes better synchronization between N clocks.
>
> Introduce a new system call multi_clock_gettime, which can be used to measure
> the offset between multiple clocks, from variety of types: PHC, virtual PHC
> and various system clocks (CLOCK_REALTIME, CLOCK_MONOTONIC, etc).
> The offset includes the total time that the driver needs to read the clock
> timestamp.

Knowing this offset sounds quite nice, but...

>
> New system call allows the reading of a list of clocks - up to PTP_MAX_CLOCKS.
> Supported clocks IDs: PHC, virtual PHC and various system clocks.
> Up to PTP_MAX_SAMPLES times (per clock) in a single system call read.
> The system call returns n_clocks timestamps for each measurement:
> - clock 0 timestamp
> - ...
> - clock n timestamp

Could this instead be arranged to read the actual, exact offset?

> +       kernel_tp = kernel_tp_base;
> +       for (j = 0; j < n_samples; j++) {
> +               for (i = 0; i < n_clocks; i++) {
> +                       if (put_timespec64(kernel_tp++, (struct __kernel_timespec __user *)
> +                                       &ptp_multi_clk_get->ts[j][i])) {
> +                               error = -EFAULT;
> +                               goto out;
> +                       }
> +               }
> +       }

There are several pairs of clocks that tick at precisely same rate
(and use the same underlying hardware clock), and the offset could be
computed exactly instead of doing this noisy loop that is merely
somewhat less bad than what user code could do all by itself.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ