On Mon, 2024-09-16 at 12:32 +0200, Thomas Gleixner wrote:
> On Mon, Sep 16 2024 at 12:12, Thomas Gleixner wrote:
> > On Sat, Sep 14 2024 at 13:07, Jeff Layton wrote:
> > > + do {
> > > + seq = read_seqcount_begin(&tk_core.seq);
> > > +
> > > + ts->tv_sec = tk->xtime_sec;
> > > + mono = tk->tkr_mono.base;
> > > + nsecs = timekeeping_get_ns(&tk->tkr_mono);
> > > + offset = *offsets[TK_OFFS_REAL];
> > > + } while (read_seqcount_retry(&tk_core.seq, seq));
> > > +
> > > + mono = ktime_add_ns(mono, nsecs);
> > > +
> > > + if (atomic64_try_cmpxchg(&mg_floor, &old, mono)) {
> > > + ts->tv_nsec = 0;
> > > + timespec64_add_ns(ts, nsecs);
> > > + } else {
> > > + /*
> > > + * Something has changed mg_floor since "old" was
> > > + * fetched. "old" has now been updated with the
> > > + * current value of mg_floor, so use that to return
> > > + * the current coarse floor value.
> >
> > 'Something has changed' is a truly understandable technical
> > explanation.
>
> old = mg_floor
> mono = T1;
> mg_floor = mono
> preemption
>
> do {
> mono = T2;
> }
>
> cmpxchg fails and the function returns a value based on T1
>
> No?
>
>
Packing for LPC, so I can't respond to all of these just now, but I
will later. You're correct, but either outcome is OK.
The requirement is that we don't hand out any values that were below
the floor at the time that the task entered the kernel. Since the time
changed while the task was already inside the kernel, either T1 or T2
would be valid timestamps.
--
Jeff Layton <jlayton@xxxxxxxxxx>
