Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Frederic Weisbecker <frederic@kernel.org>,
        Marco Elver <elver@google.com>
Cc:     syzbot <syzbot+3b14b2ed9b3d06dcaa07@syzkaller.appspotmail.com>,
        linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
        Anna-Maria Behnsen <anna-maria@linutronix.de>,
        Jacob Keller <jacob.e.keller@intel.com>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>
Subject: Re: WARNING in timer_wait_running
In-Reply-To: <ZC3z2UhQeXENKvrb@lothringen>
References: <000000000000566d5405ae2f6f70@google.com>
 <ZC3jDC6R/SGLk5vj@elver.google.com> <ZC3z2UhQeXENKvrb@lothringen>
Date:   Thu, 06 Apr 2023 21:37:40 +0200
Message-ID: <87h6tsred7.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Thu, Apr 06 2023 at 00:19, Frederic Weisbecker wrote:
> On Wed, Apr 05, 2023 at 11:07:24PM +0200, Marco Elver wrote:
>> Up-to-date warning:
>> 
>>  | WARNING: CPU: 1 PID: 6695 at kernel/time/posix-timers.c:849 timer_wait_running+0x255/0x290 kernel/time/posix-timers.c:849
>> 
>> Why is it wrong for timer_wait_running to be NULL?
>
> It appears to concern clock_posix_cpu which indeed doesn't implement
> ->timer_wait_running even though posix_cpu_timer_set() might return
> TIMER_RETRY if the timer is about to fire.
>
> Then on RT and if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y then
> timer_wait_running() must busy loop waiting for the task to complete
> the task work.
>
> We could arrange for doing the same thing as hrtimer_cancel_wait_running()
> but for posix cpu timers, with taking a similar lock within
> handle_posix_cpu_timers() that timer_wait_running() could sleep on and
> inject its PI into.

I have a faint memory that we discussed something like that, but there
was an issue which completely escaped my memory.

But yes, something like this could work.

Though we should quickly shut this warning up for the !RT case by
providing an callback which does

  WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_RT);

and let the RT folks deal with it.

Thanks,

        tglx