[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1908191752580.2147@nanos.tec.linutronix.de>
Date: Mon, 19 Aug 2019 17:59:00 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Arul Jeniston <arul.jeniston@...il.com>
cc: viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, arul_mc@...l.com
Subject: Re: [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read
function.
On Mon, 19 Aug 2019, Arul Jeniston wrote:
> hi Tglx,
> > But for the above scenario:
> >
> > ktime_get()
> > do {
> > seq = read_seqcount_begin(&tk_core.seq);
> > base = tk->tkr_mono.base;
> > nsecs = timekeeping_get_ns(&tk->tkr_mono);
> >
> > } while (read_seqcount_retry(&tk_core.seq, seq));
> >
> > So if the interrupt which updates the timekeeper hits in the middle of
> > timekeeping_get_ns() then the result is discarded because the sequence
> > count changed and read_seqcount_retry() returns true. So it takes another
> > round which will be perfectly aligned with the updated time keeper.
> >
>
> Do you mean to say the timekeeper updates always happen from ktime_get?
> My point was, when one thread is in ktime_get other thread/isr updates
> timekeeper from different flow.
Timekeeper updates happen of course NOT from ktime_get(), but ktime_get()
is protected against concurrent updates via the seqcount. Simplified
without all the required barriers etc.
ktime_get()
do {
seq = tk->seq;
if (seq & 1)
continue;
base = tk->base;
nsec = get_nsec();
while (seq != tk->seq);
update()
tk->seq++;
update_data();
tk-<seq++;
It does not matter whether the update is an interrupt on the same CPU which
hits ktime_get() or whether it happens concurrent on a different CPU.
ktime_get() can never use inconsistent tk data for calculating the time.
Thanks,
tglx
Powered by blists - more mailing lists