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
| ||
|
Message-ID: <CANDhNCryn8TjJZRdCvVUj88pakHSUvtyN53byjmAcyowKj5mcA@mail.gmail.com> Date: Fri, 29 Sep 2023 00:06:46 -0700 From: John Stultz <jstultz@...gle.com> To: Mahesh Bandewar (महेश बंडेवार) <maheshb@...gle.com> Cc: Netdev <netdev@...r.kernel.org>, Linux <linux-kernel@...r.kernel.org>, David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Jonathan Corbet <corbet@....net>, Don Hatchett <hatch@...gle.com>, Yuliang Li <yuliangli@...gle.com>, Mahesh Bandewar <mahesh@...dewar.net>, Thomas Gleixner <tglx@...utronix.de>, Stephen Boyd <sboyd@...nel.org>, Richard Cochran <richardcochran@...il.com> Subject: Re: [PATCH 1/4] time: add ktime_get_cycles64() api On Thu, Sep 28, 2023 at 11:56 PM John Stultz <jstultz@...gle.com> wrote: > On Thu, Sep 28, 2023 at 11:35 PM Mahesh Bandewar (महेश बंडेवार) > <maheshb@...gle.com> wrote: > > On Thu, Sep 28, 2023 at 10:15 PM John Stultz <jstultz@...gle.com> wrote: > > > 3) Nit: The interface is called ktime_get_cycles64 (timespec64 > > > returning interfaces usually are postfixed with ts64). > > > > > Ah, thanks for the explanation. I can change to comply with the > > convention. Does ktime_get_cycles_ts64() make more sense? > > Maybe a little (it at least looks consistent), but not really if > you're sticking raw cycles in the timespec :) > Despite my concerns that it's a bad idea, If one was going to expose raw cycles from the timekeeping core, I'd suggest doing so directly as a u64 (`u64 ktime_get_cycles(void)`). That may mean widening (or maybe using a union in) your PTP ioctl data structure to have a explicit cycles field. Or introducing a separate ioctl that deals with cycles instead of timespec64s. Squeezing data into types that are canonically used for something else should always be avoided if possible (there are some cases where you're stuck with an existing interface, but that's not the case here). But I still think we should avoid exporting the raw cycle values unless there is some extremely strong argument for it (and if we can, they should be abstracted into some sort of cookie value to avoid userland using it as a raw clock). thanks -john
Powered by blists - more mailing lists