[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aG95eBlgTIDUKX7e@hyeyoo>
Date: Thu, 10 Jul 2025 17:27:36 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Andrey Ryabinin <ryabinin.a.a@...il.com>,
Arnd Bergmann <arnd@...db.de>, Dennis Zhou <dennis@...nel.org>,
Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...two.org>,
"H . Peter Anvin" <hpa@...or.com>,
Alexander Potapenko <glider@...gle.com>,
Andrey Konovalov <andreyknvl@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Juergen Gross <jgross@...e.com>, Kevin Brodsky <kevin.brodsky@....com>,
Muchun Song <muchun.song@...ux.dev>,
Oscar Salvador <osalvador@...e.de>,
Joao Martins <joao.m.martins@...cle.com>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Jane Chu <jane.chu@...cle.com>, Alistair Popple <apopple@...dia.com>,
Mike Rapoport <rppt@...nel.org>,
Gwan-gyeong Mun <gwan-gyeong.mun@...el.com>,
"Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
linux-mm@...ck.org, stable@...r.kernel.org
Subject: Re: [RFC V1 PATCH mm-hotfixes 2/3] x86/mm: define
p*d_populate_kernel() and top-level page table sync
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@...cle.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).
Will update in the next version.
--
Cheers,
Harry / Hyeonggon
Powered by blists - more mailing lists