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>
Cc:     Marco Elver <elver@google.com>,
        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: <ZDADdMnY0oW2k5BV@lothringen>
References: <87h6tsred7.ffs@tglx> <874jpsqdy1.ffs@tglx>
 <ZDADdMnY0oW2k5BV@lothringen>
Date:   Fri, 07 Apr 2023 19:47:40 +0200
Message-ID: <87lej3twhv.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Fri, Apr 07 2023 at 13:50, Frederic Weisbecker wrote:
> On Fri, Apr 07, 2023 at 10:44:22AM +0200, Thomas Gleixner wrote:
>> Now memory came back. The problem with posix CPU timers is that it is
>> not really known to the other side which task is actually doing the
>> expiry. For process wide timers this could be any task in the process.
>> 
>> For hrtimers this works because the expiring context is known.
>
> So if posix_cpu_timer_del() were to clear ctmr->pid to NULL and then
> delay put_pid() with RCU, we could retrieve that information without
> holding the timer lock (with appropriate RCU accesses all around).

No, you can't. This only gives you the process, but the expiry might run
on any task of that. To make that work you need a mutex in sighand.

Thanks,

        tglx