linux-kernel - Re: [PATCH net-next 1/4] time64.h: define PSEC_PER

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]

Date:   Mon, 27 Jun 2022 10:06:15 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Vincenzo Frascino <vincenzo.frascino@....com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Michael Walle <michael@...le.cc>,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Maxim Kochetkov <fido_max@...ox.ru>,
        Colin Foster <colin.foster@...advantage.com>,
        Richie Pearn <richard.pearn@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH net-next 1/4] time64.h: define PSEC_PER_NSEC and use it in
 tc-taprio

On Mon, Jun 27, 2022 at 10:25:42AM +0100, Vincenzo Frascino wrote:
> Hi Vladimir,
> 
> On 6/27/22 09:51, Vladimir Oltean wrote:
> > Hi Vincenzo,
> > 
> > On Mon, Jun 27, 2022 at 08:52:51AM +0100, Vincenzo Frascino wrote:
> >> Hi Vladimir,
> >>
> >> On 6/26/22 13:05, Vladimir Oltean wrote:
> >>> Time-sensitive networking code needs to work with PTP times expressed in
> >>> nanoseconds, and with packet transmission times expressed in
> >>> picoseconds, since those would be fractional at higher than gigabit
> >>> speed when expressed in nanoseconds.
> >>>
> >>> Convert the existing uses in tc-taprio to a PSEC_PER_NSEC macro.
> >>>
> >>> Cc: Andy Lutomirski <luto@...nel.org>
> >>> Cc: Thomas Gleixner <tglx@...utronix.de>
> >>> Cc: Vincenzo Frascino <vincenzo.frascino@....com>
> >>> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> >>> ---
> >>>  include/vdso/time64.h  | 1 +
> >>>  net/sched/sch_taprio.c | 4 ++--
> >>>  2 files changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/include/vdso/time64.h b/include/vdso/time64.h
> >>> index b40cfa2aa33c..f1c2d02474ae 100644
> >>> --- a/include/vdso/time64.h
> >>> +++ b/include/vdso/time64.h
> >>> @@ -6,6 +6,7 @@
> >>>  #define MSEC_PER_SEC	1000L
> >>>  #define USEC_PER_MSEC	1000L
> >>>  #define NSEC_PER_USEC	1000L
> >>> +#define PSEC_PER_NSEC	1000L
> >>
> >> Are you planning to use this definition in the vdso library code? If not, you
> >> should define PSEC_PER_NSEC in "include/linux/time64.h". The vdso namespace
> >> should contain only the definitions shared by the implementations of the kernel
> >> and of the vdso library.
> > 
> > I am not. I thought it would be ok to preserve the locality of
> > definitions by placing this near the others of its kind, since a macro
> > doesn't affect the compiled vDSO code in any way. But if you prefer, I
> > can create a new mini-section in linux/time64.h. Any preference on where
> > exactly to place that definition within the file?
> 
> I do not have a strong opinion on where to put it. But I think that if you put a
> section above TIME64_MAX should work.

@networking people: do you mind if in v2 I move this patch to the end,
hardcode 1000 in the current DSA patch 4/4, and then replace it afterwards
with PSEC_PER_NSEC, together with tc-taprio? I'd like to leave the code
in a clean state, but remember this is also a patch that fixes a
functional issue, even if on net-next, so one dependency less can't
hurt, for those who'll want to backport.