linux-kernel - Re: [PATCH WITHDRAWN] timekeeping: Move debug sleep time accounting outside spinlock

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] [day] [month] [year] [list]

Message-ID: <tencent_8FAF92EC7B7BF79E6DA0101B3A52D6004E06@qq.com>
Date: Fri, 12 Sep 2025 18:33:23 +0800
From: Haofeng Li <920484857@...com>
To: tglx@...utronix.de
Cc: 13266079573@....com,
	920484857@...com,
	jstultz@...gle.com,
	lihaofeng@...inos.cn,
	linux-kernel@...r.kernel.org,
	sboyd@...nel.org
Subject: Re: [PATCH WITHDRAWN] timekeeping: Move debug sleep time accounting outside spinlock

>How so exactly?

>I don't see how that would deadlock, but I might miss something. So
>please explain it properly instead of handwaving about it.

>Thanks,

>        tglx

Thank you for your detailed feedback and for pointing out the issues with my previous analysis. I sincerely apologize for the oversight and any confusion it may have caused. You were absolutely right to question the reasoning, and upon re-examining the code with a fresher perspective, I realize my initial explanation was incomplete and incorrect.

Regarding your specific questions:

Removal of touch_softlockup_watchdog():
I now understand that this change was unrelated to the problem at hand. The removal was mistakenly included in the context of addressing the potential deadlock issue, which was not justified. This line should not have been touched.

Potential Deadlock in tk_debug_account_sleep_time():
Your skepticism about the deadlock risk was entirely valid. After further analysis, I confirmed that the function tk_debug_account_sleep_time()—specifically, the pm_deferred_pr_dbg() macro and its underlying printk_deferred() implementation—does not acquire any locks that could cause a deadlock, even when called within a spinlock-protected context. The deferred printk mechanism is designed to be safe in such scenarios, as it avoids locking and instead uses per-CPU buffers to handle logging.

The confusion arose because I was referencing an older version of the codebase that lacked the commit 099f1c84c005 ("printk: introduce per-cpu safe_print seq buffer"). This commit introduced critical improvements to the deferred printk functionality, ensuring it remains lock-free and safe for use in contexts like this. In the older codebase, a similar scenario could indeed lead to deadlocks, but in the current code, the implementation is robust and free of such risks.

Again, I apologize for the oversight and the time spent addressing this. I greatly appreciate your patience and thorough review, which helped me correct my misunderstanding. 

Thank you for your guidance and for holding the code to a high standard.

Best regards,

	lihaofeng