Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <85f7ce7bc7ddcf1f67b52375b7fabaca8d254e5a.camel@sipsolutions.net>
Subject: Re: UML time-travel warning from __run_timers
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Thomas Gleixner <tglx@linutronix.de>,
        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>
Date:   Mon, 04 Apr 2022 10:37:30 +0200
In-Reply-To: <87ee2dl041.ffs@tglx>
References: <20220330110156.GA9250@axis.com>
         <84f9d627092660c38400b607198c3b83f795be7f.camel@sipsolutions.net>
         <877d86m978.ffs@tglx>
         <32423b7c0e3a490093ceaca750e8669ac67902c6.camel@sipsolutions.net>
         <87pmlykksj.ffs@tglx>
         <ff314e8556aba7e231ab80c46b30701142e82a43.camel@sipsolutions.net>
         <87ee2dl041.ffs@tglx>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Mon, 2022-04-04 at 10:32 +0200, Thomas Gleixner wrote:
> On Mon, Apr 04 2022 at 09:02, Johannes Berg wrote:
> > On Sun, 2022-04-03 at 21:51 +0200, Thomas Gleixner wrote:
> > > but that's fine and it is overwritten by every timer which is inserted
> > > to expire before that. So that's not an issue as the prandom timer is
> > > firing and rearmed.
> > 
> > No, as I said before, there's never any timer with base 1 (BASE_DEF) in
> > the config we have. The prandom timer is not TIMER_DEFERRABLE (it
> > probably could be, but it's not now). There's no deferrable timer at
> > all. Once there is at least one, the warning goes away.
> 
> Groan. I overlooked the deferrable part. Yes, you are right. next_expiry
> of the deferrable base is stale when there is no timer queued up to the
> point where base->clk reaches the initial next_expiry value. So the
> check is bogus.
> 
> Thanks,
> 
>         tglx
> ---
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1724,9 +1724,8 @@ static inline void __run_timers(struct t
>  		/*
>  		 * The only possible reason for not finding any expired
>  		 * timer at this clk is that all matching timers have been
> -		 * dequeued.
> +		 * dequeued or no timer has been ever queued.
>  		 */
> -		WARN_ON_ONCE(!levels && !base->next_expiry_recalc);
> 

So I'm pretty sure we don't even need to test a patch simply removing
the WARN_ON_ONCE() since the entire problem Vincent reported was hitting
the WARN_ON_ONCE :)

(And I'm pretty sure I did at some point test some additional condition
inside it)

Are you going to merge that patch?

johannes