---------- Forwarded message --------- 发件人： Arin Sun sunxploree@gmail.com Date: 2025年7月28日周一 09:28 Subject: Re: [stable backport request] x86/ioremap: Use is_ioremap_addr() in iounmap() for 5.15.y To: Greg KH gregkh@linuxfoundation.org
Dear Greg K-H and Stable Kernel Team,
Thank you for your quick reply and for explaining the backporting considerations. I understand the need for tested backports across kernel trees to prevent regressions and appreciate your suggestion to upgrade.
Regarding your question, we are indeed planning to upgrade to the 6.12.y release in the future, as it aligns with our long-term stability and feature needs. However, due to constraints from our partners and current production dependencies, we are not able to migrate at this time. For now, we'll focus on workarounds to mitigate the issue in our 5.xx environments.
Thank you again for your time and guidance in maintaining the stable kernels.
Best regards,
Arin Sun
Greg KH gregkh@linuxfoundation.org 于2025年7月25日周五 20:03写道：
On Fri, Jul 25, 2025 at 06:32:50PM +0800, Arin Sun wrote:
Dear Stable Kernel Team and Maintainers,
I am writing to request a backport of the following commit from the mainline kernel to the 5.15.y stable branch:
Commit: x86/ioremap: Use is_ioremap_addr() in iounmap() ID: 50c6dbdfd16e312382842198a7919341ad480e05 Author: Max Ramanouski Merged in: Linux 6.11-rc1 (approximately August 2024)
It showed up in 6.12, not 6.11.
This commit fixes a bug in the iounmap() function for x86 architectures in kernel versions 5.x. Specifically, the original code uses a check against high_memory:
if ((void __force *)addr <= high_memory) return;
This can lead to memory leaks on certain x86 servers where ioremap() returns addresses that are not guaranteed to be greater than high_memory, causing the function to return early without properly unmapping the memory.
The fix replaces this with is_ioremap_addr(), making the check more reliable:
if (WARN_ON_ONCE(!is_ioremap_addr((void __force *)addr))) return;
I have checked the 5.15.y branch logs and did not find this backport. This issue affects production environments, particularly on customer machines where we cannot easily deploy custom kernels. Backporting this to 5.15.y (and possibly other LTS branches like 5.10.y if applicable) would help resolve the memory leak without requiring users to upgrade to 6.x series.
Do you have plans to backport this commit? If not, could you please consider it for inclusion in the stable releases?
Note, this caused problems that later commits were required to fix up.
Can you please provide a set of properly backported commits, that are tested, to all of the relevant kernel trees that you need/want this for? You can't just apply a patch to an older kernel tree and not a newer one as that would cause a regression when upgrading, right?
But I might ask, why not just move to the 6.12.y release? What is forcing you to keep on 5.15.y and what are you plans for moving off of that in a few years?
thanks,
greg k-h