netdev - Re: [PATCH v7] posix-timers: add 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: <ZfMe66MfHBEfxrdd@FVFF77S0Q05N>
Date: Thu, 14 Mar 2024 15:59:39 +0000
From: Mark Rutland <mark.rutland@....com>
To: Sagi Maimon <maimon.sagi@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, 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, mszeredi@...hat.com,
	casey@...aufler-ca.com, reibax@...il.com, davem@...emloft.net,
	brauner@...nel.org, linux-kernel@...r.kernel.org,
	linux-api@...r.kernel.org, linux-arch@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH v7] posix-timers: add clock_compare system call

On Thu, Mar 14, 2024 at 02:19:39PM +0200, Sagi Maimon wrote:
> On Thu, Mar 14, 2024 at 1:12 PM Thomas Gleixner <tglx@...utronix.de> wrote:
> > On Thu, Mar 14 2024 at 11:05, Sagi Maimon wrote:
> > > +     if (crosstime_support_a) {
> > > +             ktime_a = ktime_sub(xtstamp_a2.device, xtstamp_a1.device);
> > > +             ts_offs_err = ktime_divns(ktime_a, 2);
> > > +             ktime_a = ktime_add_ns(xtstamp_a1.device, (u64)ts_offs_err);
> > > +             ts_a1 = ktime_to_timespec64(ktime_a);
> >
> > This is just wrong.
> >
> >      read(a1);
> >      read(b);
> >      read(a2);
> >
> > You _CANNOT_ assume that (a1 + ((a2 - a1) / 2) is anywhere close to the
> > point in time where 'b' is read. This code is preemtible and
> > interruptible. I explained this to you before.
> >
> > Your explanation in the comment above the function is just wishful
> > thinking.
> >
> you explained it before, but still it is better then two consecutive
> user space calls which are also preemptible
> and the userspace to kernel context switch time is added.

How much "better" is that in reality?

The time for a user<->kernel transition should be trivial relative to the time
a task spends not running after having been preempted.

Either:

(a) Your userspace application can handle the arbitrary delta resulting from a
    preemption, in which case the trivial cost shouldn't matter.

    i.e. this patch *is not necessary* to solve your problem.

(b) Your userspace application cannot handle the arbitrary delta resulting from
    a preemption, in which case you need to do something to handle that, which
    you haven't described at all.
  
    i.e. with the information you have provided so far, this patch is
    *insufficient* to solve your problem.

> > > + * In other cases: Read clock_a twice (before, and after reading clock_b) and
> > > + * average these times – to be as close as possible to the time we read clock_b.
> >
> > Can you please sit down and provide a precise technical description of
> > the problem you are trying to solve and explain your proposed solution
> > at the conceptual level instead of throwing out random implementations
> > every few days?

100% agreed.

Please, explain the actual problem you are solving here. What *specifically*
are you trying to do in userspace with these values? "Synchronization" is too
vague a description.

Making what is already the best case *marginally better* without handling the
common and worst cases is a waste of time. It doesn't actually solve the
problem, and it misleads people into thinknig that a problem is solved when it
is not.

Mark.