[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aHCMwOqzLrO8tzaq@hyeyoo>
Date: Fri, 11 Jul 2025 13:02:08 +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 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@...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).
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.
> Will update in the next version.
>
> --
> Cheers,
> Harry / Hyeonggon
>
--
Cheers,
Harry / Hyeonggon
Powered by blists - more mailing lists