linux-kernel - Re: WARNING in timer_wait

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 06 Apr 2023 21:37:40 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Frederic Weisbecker <frederic@...nel.org>,
        Marco Elver <elver@...gle.com>
Cc:     syzbot <syzbot+3b14b2ed9b3d06dcaa07@...kaller.appspotmail.com>,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        Anna-Maria Behnsen <anna-maria@...utronix.de>,
        Jacob Keller <jacob.e.keller@...el.com>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: WARNING in timer_wait_running

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