On Tue, 2026-06-02 at 11:31 +0200, Thomas Gleixner wrote:
> On Sat, May 30 2026 at 13:08, Rodolfo Giometti wrote:
> > On 29/05/2026 22:00, Thomas Gleixner wrote:
> > > static inline void pps_get_ts(struct pps_event_time *ts)
> > > {
> > > +#ifdef CONFIG_NTP_PPS
> > > struct system_time_snapshot snap;
> > >
> > > - ktime_get_snapshot(&snap);
> > > - ts->ts_real = ktime_to_timespec64(snap.real);
> > > -#ifdef CONFIG_NTP_PPS
> > > - ts->ts_raw = ktime_to_timespec64(snap.raw);
> > > + ktime_get_snapshot_id(CLOCK_REALTIME, &snap);
> > > + ts->ts_real = ktime_to_timespec64(snap.systime);
> > > + ts->ts_raw = ktime_to_timespec64(snap.monoraw);
> > > +#else
> > > + ktime_get_real_ts64(&ts->ts_real);
> >
> > /*
> > * Prevent kernel stack information disclosure if the
> > * structure is later copied to userspace.
> > */
> > ts->ts_raw = (struct timespec64){0, 0};
>
> Which will fail to build because of:
>
> struct pps_event_time {
> #ifdef CONFIG_NTP_PPS
> struct timespec64 ts_raw;
> #endif /* CONFIG_NTP_PPS */
> struct timespec64 ts_real;
> };
>
> No?I think we should kill struct pps_event_time and just use a system_time_snapshot anyway. And I think we can make CONFIG_NTP_PPS work for NOHZ too. If I understand correctly, the main problem with NOHZ is that without a tick, the reported CLOCK_REALTIME sawtooths much more around the time that the core timekeeping *wants* to report. That is, tk->ntp_error goes much higher and much lower, than when the precise 'mult' rate can be re-adjusted every tick to keep it on course. If we add an ntp_error field to the system_time_snapshot, the PPS code could use that to correct the CLOCK_REALTIME value and the jitter that NOHZ introduces wouldn't matter.
smime.p7s
Description: S/MIME cryptographic signature
