Stephen Brennan <stephen.s.brennan@xxxxxxxxxx> writes: > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: > >> On Fri, 7 Jun 2024 13:29:53 -0700 Stephen Brennan <stephen.s.brennan@xxxxxxxxxx> wrote: >> >>> Changing PG_slab from a page flag to a page type in commit 46df8e73a4a3 >>> ("mm: free up PG_slab") in has the unintended consequence of removing >>> the PG_slab constant from kernel debuginfo. The commit does add the >>> value to the vmcoreinfo note, which allows debuggers to find the value >>> without hardcoding it. However it's most flexible to continue >>> representing the constant with an enum. To that end, convert the page >>> type fields into an enum. Debuggers will now be able to detect that >>> PG_slab's type has changed from enum pageflags to enum pagetype. >>> >>> Fixes: 46df8e73a4a3 ("mm: free up PG_slab") >> >> Should we backport this into 6.9.x? > > Hi Andrew, > > Looks like commit 46df8e73a4a3 ("mm: free up PG_slab") is introduced in > the v6.10-rc's, and not backported to 6.9. So PG_slab is still part of Hi Andrew, I saw that you've merged this into mm-unstable, thank you! Since 46df8e73a4a3 ("mm: free up PG_slab") is part of the current 6.10 RC, it would be great if this patch could be part of the 6.10 release so we don't release a kernel missing the PG_slab info. Can you confirm if mm-unstable will get merged in this release cycle? Or else, would it be possible to include it in a branch that will? Thanks, Stephen > enum pageflags in 6.9. From the perspective of the issue which motivated > this patch, there's no reason to backport. > > Backporting could make the other enum pagetype constants available in > 6.9, but I'm not sure there are any users who would care for that. I'd > say there's no need. > > Thanks, > Stephen