On Thu, Aug 14, 2025 at 04:54:33PM +0200, Greg Kroah-Hartman wrote:
On Thu, Aug 14, 2025 at 03:38:23PM +0100, Catalin Marinas wrote:
On Thu, Aug 14, 2025 at 03:56:58PM +0200, Greg Kroah-Hartman wrote:
On Thu, Aug 14, 2025 at 02:08:35PM +0100, Catalin Marinas wrote:
On Thu, Aug 14, 2025 at 10:33:56AM +0800, Gu Bowen wrote:
On 8/14/2025 6:56 AM, Andrew Morton wrote:
I'm not sure which kernel version this was against, but kmemleak.c has changed quite a lot.
Could we please see a patch against a latest kernel version? Linus mainline will suit.
Thanks.
I discovered this issue in kernel version 5.10. Afterwards, I reviewed the code of the mainline version and found that this deadlock path no longer exists due to the refactoring of console_lock in v6.2-rc1. For details on the refactoring, you can refer to this link : https://lore.kernel.org/all/20221116162152.193147-1-john.ogness@linutronix.d.... Therefore, theoretically, this issue existed before the refactoring of console_lock.
Oh, so you can no longer hit this issue with mainline. This wasn't mentioned (or I missed it) in the commit log.
So this would be a stable-only fix that does not have a correspondent upstream. Adding Greg for his opinion.
Why not take the upstream changes instead?
Gu reckons there are 40 patches - https://lore.kernel.org/all/20221116162152.193147-1-john.ogness@linutronix.d...
40 really isn't that much overall, we've taken way more for much smaller issues :)
TBH, I'm not sure it's worth it. That's a potential deadlock on a rare error condition (a kmemleak bug or something wrong with the sites calling the kmemleak API).
I haven't checked what ended in mainline and whether we could do with fewer backports.
I'll leave that all up to the people who are still wanting these older kernels.
Good point. Thanks for the advice ;).