On Fri, Jul 11, 2025 at 01:02:08PM +0900, Harry Yoo wrote:
On Thu, Jul 10, 2025 at 05:27:36PM +0900, Harry Yoo wrote:
On Wed, Jul 09, 2025 at 02:13:59PM -0700, Andrew Morton wrote:
On Wed, 9 Jul 2025 22:16:56 +0900 Harry Yoo harry.yoo@oracle.com wrote:
Fixes: 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps") Fixes: faf1c0008a33 ("x86/vmemmap: optimize for consecutive sections in partial populated PMDs")
Fortunately both of these appeared in 6.9-rc7, which minimizes the problem with having more than one Fixes:.
But still, the Fixes: is a pointer telling -stable maintainers where in the kernel history we want them to insert the patch(es). Giving them multiple insertions points is confusing! Can we narrow this down to a single Fixes:?
If I had to choose only one I think it should be 4917f55b4ef9, since faf1c0008a33 is not yet known to be triggered without enlarging struct page (and once it's backported it fixes both of them).
On second look, faf1c0008a33 is introduced in v5.13-rc1 and 4917f55b4ef9 is introduced in v5.19-rc1.
I'll go with Fixes: faf1c0008a33 because it's introduced earlier.
Uh, on third look Fixes: faf1c0008a33 is incorrect :/ It's Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges").
This is the commit that started initializing unused vmemmap with PAGE_UNUSED, and can lead to bugs when current task's mm is not init_mm because as accessing vmemmap before sync_global_pgds().