linux-kernel - Re: [PATCH v3] posix-timers: add multi_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: <CAMuE1bF4sSeiDr-jyebF6F8oRxGs1b2gtT39fTJ2JeaFabr6Ng@mail.gmail.com>
Date: Mon, 15 Jan 2024 17:49:32 +0200
From: Sagi Maimon <maimon.sagi@...il.com>
To: Richard Cochran <richardcochran@...il.com>
Cc: Arnd Bergmann <arnd@...db.de>, Andy Lutomirski <luto@...nel.org>, tglx@...utronix.de, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, Geert Uytterhoeven <geert@...ux-m68k.org>, 
	Peter Zijlstra <peterz@...radead.org>, Johannes Weiner <hannes@...xchg.org>, 
	Sohil Mehta <sohil.mehta@...el.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>, 
	Nhat Pham <nphamcs@...il.com>, Palmer Dabbelt <palmer@...ive.com>, Kees Cook <keescook@...omium.org>, 
	Alexey Gladkov <legion@...nel.org>, Mark Rutland <mark.rutland@....com>, linux-kernel@...r.kernel.org, 
	linux-api@...r.kernel.org, Linux-Arch <linux-arch@...r.kernel.org>, 
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v3] posix-timers: add multi_clock_gettime system call

On Thu, Jan 11, 2024 at 9:31 AM Richard Cochran
<richardcochran@...il.com> wrote:
>
> On Tue, Jan 02, 2024 at 12:29:59PM +0100, Arnd Bergmann wrote:
>
> > I think Andy's suggestion of exposing time offsets instead
> > of absolute times would actually achieve that: If the
> > interface is changed to return the offset against
> > CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW or CLOCK_BOOTTIME
> > (not sure what is best here), then the new syscall can use
> > getcrosststamp() where supported for the best results or
> > fall back to gettimex64() or gettime64() otherwise to
> > provide a consistent user interface.
>
> Yes, it makes more sense to provide the offset, since that is what the
> user needs in the end.
>
Make sense will be made on the next patch.
> Can we change the name of the system call to "clock compare"?
>
> int clock_compare(clockid_t a, clockid_t b,
>                   int64_t *offset, int64_t *error);
>
> returns: zero or error code,
>  offset = a - b
>  error  = maximum error due to asymmetry
>
> If clocks a and b are both System-V clocks, then *error=0 and *offset
> can be returned directly from the kernel's time keeping state.
>
> If getcrosststamp() is supported on a or b, then invoke it.
>
> otherwise do this:
>
>    t1 = gettime(a)
>    t2 = gettime(b)
>    t3 - gettime(c)
>
>    *offset = (t1 + t3)/2 - t2
>    *error  = (t3 - t1)/2
>
> There is no need for repeated measurement, since user space can call
> again when `error` is unacceptable.
>
Thanks for your notes, all of them will be done on the next patch (it
will take some time due to work overload).
The only question that I have is: why not implement it as an IOCTL?
It makes more sense to me since it is close to another IOCTL, the
"PTP_SYS_OFFSET" family.
Does it make sense to you?

> Thanks,
> Richard
>
>
>