All of lore.kernel.org
 help / color / mirror / Atom feed
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 14:17:15 +0200	[thread overview]
Message-ID: <871qydjb5g.ffs@tglx> (raw)
In-Reply-To: <85f7ce7bc7ddcf1f67b52375b7fabaca8d254e5a.camel@sipsolutions.net>

On Mon, Apr 04 2022 at 10:37, Johannes Berg wrote:
> On Mon, 2022-04-04 at 10:32 +0200, Thomas Gleixner wrote:
>> --- 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?

Let me write a coherent changelog.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


WARNING: multiple messages have this Message-ID (diff)
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 14:17:15 +0200	[thread overview]
Message-ID: <871qydjb5g.ffs@tglx> (raw)
In-Reply-To: <85f7ce7bc7ddcf1f67b52375b7fabaca8d254e5a.camel@sipsolutions.net>

On Mon, Apr 04 2022 at 10:37, Johannes Berg wrote:
> On Mon, 2022-04-04 at 10:32 +0200, Thomas Gleixner wrote:
>> --- 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?

Let me write a coherent changelog.

  reply	other threads:[~2022-04-04 12:17 UTC|newest]

Thread overview: 26+ 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 11:01 ` Vincent Whitchurch
2022-03-30 12:33 ` Johannes Berg
2022-03-30 12:33   ` Johannes Berg
2022-04-02 14:09 ` Johannes Berg
2022-04-02 14:09   ` Johannes Berg
2022-04-02 14:17   ` Johannes Berg
2022-04-02 14:17     ` Johannes Berg
2022-04-03 16:18   ` Thomas Gleixner
2022-04-03 16:18     ` Thomas Gleixner
2022-04-03 17:13     ` Johannes Berg
2022-04-03 17:13       ` Johannes Berg
2022-04-03 17:19       ` Johannes Berg
2022-04-03 17:19         ` Johannes Berg
2022-04-03 23:23         ` Thomas Gleixner
2022-04-03 23:23           ` Thomas Gleixner
2022-04-03 19:51       ` Thomas Gleixner
2022-04-03 19:51         ` Thomas Gleixner
2022-04-04  7:02         ` Johannes Berg
2022-04-04  7:02           ` Johannes Berg
2022-04-04  8:32           ` Thomas Gleixner
2022-04-04  8:32             ` Thomas Gleixner
2022-04-04  8:37             ` Johannes Berg
2022-04-04  8:37               ` Johannes Berg
2022-04-04 12:17               ` Thomas Gleixner [this message]
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=871qydjb5g.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.