From: Thomas Gleixner <tglx@linutronix.de>
To: Johannes Berg <johannes@sipsolutions.net>,
Vincent Whitchurch <vincent.whitchurch@axis.com>
Cc: linux-um@lists.infradead.org, linux-kernel@vger.kernel.org,
Anna-Maria Gleixner <anna-maria@linutronix.de>,
Frederic Weisbecker <frederic@kernel.org>
Subject: Re: UML time-travel warning from __run_timers
Date: Mon, 04 Apr 2022 01:23:01 +0200 [thread overview]
Message-ID: <87h779lpka.ffs@tglx> (raw)
In-Reply-To: <43785c9c6ee74a995963144946c67893ebbf8852.camel@sipsolutions.net>
Johannes,
On Sun, Apr 03 2022 at 19:19, Johannes Berg wrote:
> Actually, in a sense, this *is* the case of (just) recalculating
> next_expiry, no? We just never set next_expiry_recalc since there was
> never any timer on this?
why are you insisting on fishing in the dark?
> So actually this also makes the warning go away:
>
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1729,6 +1733,7 @@ static inline void __run_timers(struct timer_base *base)
> WARN_ON_ONCE(!levels && !base->next_expiry_recalc);
> base->clk++;
> base->next_expiry = __next_timer_interrupt(base);
> + base->next_expiry_recalc = !levels;
You are papering over the problem. That makes the warnign go away, but
does not explain anyhting about the root cause. Can you please provide
the information which was asked for?
> while (levels--)
> expire_timers(base, heads + levels);
> @@ -2005,6 +2010,7 @@ static void __init init_timer_cpu(int cpu)
> raw_spin_lock_init(&base->lock);
> base->clk = jiffies;
> base->next_expiry = base->clk + NEXT_TIMER_MAX_DELTA;
> + base->next_expiry_recalc = true;
This is complete nonsense because at the point where the CPU base is
initialized next_expiry _IS_ correct at the outer max. Why would it be
required to be recalculated? The only reason why it needs to be
recalculated is when a timer is canceled before expiry, but there is
_NO_ timer which can be canceled at this point.
So what are you trying to solve here?
Thanks,
tglx
next prev parent reply other threads:[~2022-04-03 23:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 11:01 UML time-travel warning from __run_timers Vincent Whitchurch
2022-03-30 12:33 ` Johannes Berg
2022-04-02 14:09 ` Johannes Berg
2022-04-02 14:17 ` Johannes Berg
2022-04-03 16:18 ` Thomas Gleixner
2022-04-03 17:13 ` Johannes Berg
2022-04-03 17:19 ` Johannes Berg
2022-04-03 23:23 ` Thomas Gleixner [this message]
2022-04-03 19:51 ` Thomas Gleixner
2022-04-04 7:02 ` Johannes Berg
2022-04-04 8:32 ` Thomas Gleixner
2022-04-04 8:37 ` Johannes Berg
2022-04-04 12:17 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h779lpka.ffs@tglx \
--to=tglx@linutronix.de \
--cc=anna-maria@linutronix.de \
--cc=frederic@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=vincent.whitchurch@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox