Hi, Greg,
On Sat, Jun 25, 2022 at 10:07 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Sat, Jun 25, 2022 at 10:00:43PM +0800, Huacai Chen wrote:
> > Hi, Muchun,
> >
> > On Sat, Jun 25, 2022 at 7:17 PM Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote:
> > >
> > > On Sat, Jun 25, 2022 at 5:04 PM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
> > > >
> > > > Hi, Muchun,
> > > >
> > > > On Sat, Jun 25, 2022 at 4:50 PM Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote:
> > > > >
> > > > > On Sat, Jun 25, 2022 at 4:04 PM Feiyang Chen
> > > > > <chris.chenfeiyang@xxxxxxxxx> wrote:
> > > > > >
> > > > > > The page-flags.h header relies on static keys since commit
> > > > > > a6b40850c442bf ("mm: hugetlb: replace hugetlb_free_vmemmap_enabled
> > > > > > with a static_key"), so make sure to include the header to avoid
> > > > > > compilation errors.
> > > > > >
> > > > > > Fixes: a6b40850c442bf ("mm: hugetlb: replace hugetlb_free_vmemmap_enabled with a static_key")
> > > > > > Cc: stable@xxxxxxxxxxxxxxx
> > > > > > Signed-off-by: Feiyang Chen <chenfeiyang@xxxxxxxxxxx>
> > > > > > ---
> > > > > > include/linux/page-flags.h | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> > > > > > index e66f7aa3191d..147b336c7a35 100644
> > > > > > --- a/include/linux/page-flags.h
> > > > > > +++ b/include/linux/page-flags.h
> > > > > > @@ -11,6 +11,7 @@
> > > > > > #include <linux/mmdebug.h>
> > > > > > #ifndef __GENERATING_BOUNDS_H
> > > > > > #include <linux/mm_types.h>
> > > > > > +#include <linux/static_key.h>
> > > > >
> > > > > I did not include this. The change makes sense to me. But I am
> > > > > curious what configs cause the compiling error. Would you mind
> > > > > sharing the config with us?
> > > > We found this problem when we add
> > > > ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP to LoongArch. Since this isn't
> > >
> > > Good news to me. I would love to hear more archs support for HVO (HugeTLB
> > > Vmemmap Optimization).
> > >
> > > > upstream yet, we cannot give such a config now (the default config of
> > > > X86 and ARM64 is just OK).
> > >
> > > All right. In this case, the "Cc: stable@xxxxxxxxxxxxxxx" is unnecessary.
> > Maybe make randconfig will have problems on X86/ARM64, so backporting
> > to 5.18 seems reasonable.
>
> Unless it is proven to be needed, there is no need to backport it.
OK, we will try "make randconfig". And if it isn't needed, should we
send V2 to remove Cc stable?
Huacai
>
> thanks,
>
> greg k-h
