linux-kernel - 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]

Date: Mon, 01 Apr 2024 22:46:10 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Sagi Maimon <maimon.sagi@...il.com>
Cc: richardcochran@...il.com, luto@...nel.org, 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, 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

Sagi!

On Thu, Mar 28 2024 at 17:40, Sagi Maimon wrote:
> On Sat, Mar 23, 2024 at 2:38 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>> On top this needs an analyis whether any of the gettimex64()
>> implementations does something special instead of invoking the
>> ptp_read_system_prets() and ptp_read_system_postts() helpers as close as
>> possible to the PCH readout, but that's not rocket science either. It's
>> just 21 callbacks to look at.
>>
> I like your suggestion, thanks!
> it is what our user space needs from the kernel and with minimum kernel changes.
> I will write it, test it and upload it with your permission (it is you
> idea after all).

You don't need permission. I made a suggestion and when you are doing the
work I'm not in a position to veto posting it. We have an explicit tag
for that 'Suggested-by:', which only says that someone suggested it to
you, but then you went and implemented it, made sure it works etc.

>> It might also require a new set of variant '3' IOTCLS to make that flag
>> field work, but that's not going to make the change more complex and
>> it's an exercise left to the experts of that IOCTL interface.
>>
> I think that I understand your meaning.
> There is a backward compatibility problem here.
>
> Existing user space application using PTP_SYS_OFFSET_EXTENDED ioctl
> won't have any problems because of the "extoff->rsv[0] ||
> extoff->rsv[1] || extoff->rsv[2]" test, but what about all old user
> space applications using: PTP_SYS_OFFSET ?

So if there is a backwards compability issue with PTP_SYS_OFFSET2, then
you need to introduce PTP_SYS_OFFSET3. The PTP_SYS_*2 variants were
introduced to avoid backwards compatibility issues as well, but
unfortunately that did not address the reserved fields problem for
PTP_SYS_OFFSET2. PTP_SYS_OFFSET_EXTENDED2 should just work, but maybe
the PTP maintainers want a full extension to '3'. Either way is fine.

Thanks,

        tglx