From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 669D417745 for ; Fri, 19 Jun 2026 19:12:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781896344; cv=none; b=Ch3l3fL28mydKKEhPBgUBiSOjNg/Lj9ziASBX35uikILfVsjGMkFojCUOX+Fk/J/P6rne6Z0IEoOF8NBNb69iBvBT55LBc5f9anrJV8Ei4YWjA2f9kseFrzCtlwiVX0Cq0xCPGJdMax34thbxHV9F05+De5rzaZHA5lx1ZYaD9w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781896344; c=relaxed/simple; bh=Phm4tvlTHXz64bchdFXiCV4WE5zFRtuX8KteO1lSMq8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=OS1ifXrbzBucgwln+sFDFj+RDvp5AAEEY4dKBfx4K05JtUDNkvjeB3nCyS8wEEUzObUYl6qLbBk7M7l6DZich0A8ONf9ZmXy5WBprbMtj9wj5z46SzCk0mfU5nBQXQEZ/ybVQf5ewhRZnh1Hotp3tO9YjUIDZe7HklbnxBxaDg0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=15GZx1L6; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=8iceQs2l; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="15GZx1L6"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="8iceQs2l" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1781896341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dFgB8i6le9iylz/FYN0qOHONj+Id6r152PaYtZjKKFI=; b=15GZx1L6mqcSWoaSKWWsqDJ95S2h2p5NtT0lhhpG5tOMiZERAsgBZpHp6hz0iniAOfuN0P Q4RE1BUn69bJHJ5RcZK0zmS1l2kLd1+ad358lK0TyiqozHkV59W2ThSVMEvLMbI+mQJGoG a82Ecwke6towW0an6K8s3CB1bx4KBRFj5TV1ovX4FIODdBo7wjUY8Fjjln607BiVDni27S wDYSnrvpHG5f86g7DezON87iGhNXXdsI7wNAxJpYwAY98b+nKVgFsDzebR34WZMjh7/XdL QFuJVjPi/hyvNR6fPf1JNO4RLzkoHqFiVKSGfZi2r4yJtMnnvRmWR2h5XLYbBA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1781896341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dFgB8i6le9iylz/FYN0qOHONj+Id6r152PaYtZjKKFI=; b=8iceQs2lwVDj0oUmda98Zrmewu53o5PW5jIeuFdVIHD7ZfTkzb1GyBlaI0IsfhWDbbB0x9 tuwRKkCOu05euyDA== To: Surya Sai Madhu Cc: anna-maria@linutronix.de, frederic@kernel.org, peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org, Surya Sai Madhu , syzbot+5e8dda76ca21dae314b6@syzkaller.appspotmail.com Subject: Re: [PATCH] hrtimer: Fix missing debug object calls in in-place update path In-Reply-To: <20260619131326.125730-1-suryasaimadhu369@gmail.com> References: <20260619131326.125730-1-suryasaimadhu369@gmail.com> Date: Fri, 19 Jun 2026 21:12:20 +0200 Message-ID: <87bjd6cpkb.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Fri, Jun 19 2026 at 21:13, Surya Sai Madhu wrote: > Commit 343f2f4dc542 ("hrtimer: Try to modify timers in place") > introduced an optimization that updates the timer expiry in-place > without dequeuing and re-enqueuing it when the new expiry falls > within the range of neighbouring timers. > > However, the in-place path skips debug_hrtimer_deactivate() and > debug_hrtimer_activate() calls, leaving the ODEBUG state machine > out of sync. When ODEBUG subsequently sees the timer in an > unexpected state, hrtimer_fixup_assert_init() fires and installs > stub_timer() as the callback. When the timer then expires, > stub_timer() hits WARN_ON(1) causing a kernel panic. The debugobjects state of the timer is ACTIVE, otherwise it would not be enqueued. hrtimer_fixup_assert_init() does not fire subsequently at all. It is invoked on the first attempt to activate the non-initialized timer and that is _before_ the timer was started the first time. See hrtimer_start_range_ns() and hrtimer_start_range_ns_user(). So no, there is nothing out of sync and nothing to fix here. Your patch is just a pointless exercise switching the debug objects state from ACTIVE to INACTIVE and back to ACTIVE. The real problem is somewhere else and has nothing to do with modify in place. Unfortunately the WARN() which is emitted by the debugobjects fixup function, which also installs the stub_timer callback via hrtimer_fixup_assert_init(), is not in the console log. That's puzzling. Thanks, tglx