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 _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
