From: sashiko-bot@kernel.org
To: "Muchun Song" <songmuchun@bytedance.com>,
"David Hildenbrand" <david@kernel.org>,
"Madhavan Srinivasan" <maddy@linux.ibm.com>,
"Mike Rapoport" <rppt@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>
Cc: "Lance Yang" <lance.yang@linux.dev>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Christophe Leroy" <chleroy@kernel.org>,
"Ritesh Harjani" <ritesh.list@gmail.com>,
"Shrikanth Hegde" <sshegde@linux.ibm.com>,
"Oscar Salvador" <osalvador@suse.de>,
"Qi Zheng" <qi.zheng@linux.dev>,
"Muchun Song" <muchun.song@linux.dev>,
"Huacai Chen" <chenhuacai@kernel.org>,
"WANG Xuerui" <kernel@xen0n.name>,
linux-mm@kvack.org, x86@kernel.org, linux-s390@vger.kernel.org,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH v2 2/5] powerpc/mm: drop powerpc vmemmap_can_optimize()
Date: Thu, 05 Nov 2026 07:16:48 +0000 [thread overview]
Message-ID: <sashiko-outbox-198652@kernel.org> (raw)
In-Reply-To: <20261105061217.13302-3-songmuchun@bytedance.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] mm: undeclared vmemmap in section_vmemmap_optimization_disable()
- [Low] mm: define vmemmap_optimizable_order() before section_vmemmap_optimizable()
--
commit e51c76b2ae2d335e25edd03780c815eb467b564b
Author: Muchun Song <muchun.song@linux.dev>
powerpc/mm: drop powerpc vmemmap_can_optimize()
This commit adds section_vmemmap_optimization_disable() to disable vmemmap
optimization in architecture fallback paths such as PowerPC Hash MMU, and
removes the PowerPC-specific vmemmap_can_optimize() override.
[ ... ]
> diff --git a/include/linux/vmemmap-optimization.h b/include/linux/vmemmap-optimization.h
> index 858311a71b0cc..5c09da4df4d83 100644
> --- a/include/linux/vmemmap-optimization.h
> +++ b/include/linux/vmemmap-optimization.h
> @@ -57,6 +57,27 @@ static inline void section_set_compound_order_range(unsigned long pfn,
> section_set_compound_order(__nr_to_section(section_nr + i), order);
> }
>
> +static inline bool section_vmemmap_optimizable(const struct mem_section *section)
> +{
> + return vmemmap_optimizable_order(section_compound_order(section));
> +}
[Severity: Low]
Will moving section_vmemmap_optimizable() here break the build at this
commit when CONFIG_VMEMMAP_OPTIMIZATION is enabled?
At this point in include/linux/vmemmap-optimization.h,
vmemmap_optimizable_order() has not been declared yet and is only defined at
the end of the header after the #endif for CONFIG_VMEMMAP_OPTIMIZATION:
include/linux/vmemmap-optimization.h:
static inline bool vmemmap_optimizable_order(unsigned int order)
{
if (!IS_ENABLED(CONFIG_VMEMMAP_OPTIMIZATION))
return false;
...
}
Compiling translation units that include linux/vmemmap-optimization.h with
CONFIG_VMEMMAP_OPTIMIZATION=y fails with an implicit declaration of
vmemmap_optimizable_order() followed by a static declaration following a
non-static declaration.
A later commit in the series ("mm/sparse-vmemmap: drop
vmemmap_can_optimize()") moves vmemmap_optimizable_order() above the
#ifdef CONFIG_VMEMMAP_OPTIMIZATION block. Could that move of
vmemmap_optimizable_order() be done in this patch instead to keep the series
bisectable?
> +
> +static inline void section_vmemmap_optimization_disable(unsigned long start,
> + unsigned long end)
> +{
> + unsigned long pfn = page_to_pfn((struct page *)start);
[Severity: Low]
Could calling page_to_pfn() inside section_vmemmap_optimization_disable()
cause a build failure on architectures such as LoongArch that include
linux/vmemmap-optimization.h before defining vmemmap?
When CONFIG_VMEMMAP_OPTIMIZATION (and therefore CONFIG_SPARSEMEM_VMEMMAP) is
enabled, page_to_pfn() in include/asm-generic/memory_model.h expands to
reference vmemmap:
#define __pfn_to_page(pfn) (vmemmap + (pfn))
#define __page_to_pfn(page) (unsigned long)((page) - vmemmap)
However, include/linux/vmemmap-optimization.h does not include a header that
defines vmemmap, and arch/loongarch/include/asm/pgtable.h includes
linux/vmemmap-optimization.h to obtain MAX_FOLIO_VMEMMAP_ALIGN before it
defines the vmemmap macro:
arch/loongarch/include/asm/pgtable.h:
#include <linux/mm_types.h>
#include <linux/mmzone.h>
#include <linux/vmemmap-optimization.h>
#include <asm/fixmap.h>
#include <asm/sparsemem.h>
...
#define VMEMMAP_ALIGN max(PMD_SIZE, MAX_FOLIO_VMEMMAP_ALIGN)
#define vmemmap ((struct page *)(ALIGN(VMALLOC_END, VMEMMAP_ALIGN)))
Because section_vmemmap_optimization_disable() is a static inline function
parsed before the vmemmap macro is defined, doesn't vmemmap remain an
undeclared identifier in page_to_pfn() when compiling on LoongArch with
CONFIG_VMEMMAP_OPTIMIZATION enabled?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105061217.13302-1-songmuchun@bytedance.com?part=2
next prev parent reply other threads:[~2026-11-05 7:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 6:12 [PATCH v2 0/5] mm: Simplify device DAX vmemmap optimization plumbing Muchun Song
2026-11-05 6:12 ` Muchun Song
2026-11-05 6:12 ` [PATCH v2 1/5] powerpc/mm: make vmemmap_populate_compound_pages() static Muchun Song
2026-11-05 6:12 ` Muchun Song
2026-11-05 7:16 ` sashiko-bot
2026-11-06 4:38 ` Lance Yang
2026-11-06 4:38 ` Lance Yang
2026-11-05 6:12 ` [PATCH v2 2/5] powerpc/mm: drop powerpc vmemmap_can_optimize() Muchun Song
2026-11-05 6:12 ` Muchun Song
2026-11-05 7:16 ` sashiko-bot [this message]
2026-11-05 8:02 ` Lance Yang
2026-11-06 6:09 ` Muchun Song
2026-11-06 9:48 ` Lance Yang
2026-11-05 12:13 ` kernel test robot
2026-11-05 12:13 ` kernel test robot
2026-11-05 6:12 ` [PATCH v2 3/5] loongarch/mm: disable device DAX vmemmap optimization Muchun Song
2026-11-05 6:12 ` Muchun Song
2026-11-05 7:16 ` sashiko-bot
2026-11-05 6:12 ` [PATCH v2 4/5] mm/sparse-vmemmap: drop vmemmap_can_optimize() Muchun Song
2026-11-05 6:12 ` Muchun Song
2026-11-05 7:16 ` sashiko-bot
2026-11-05 6:12 ` [PATCH v2 5/5] mm/sparse-vmemmap: drop @pgmap from vmemmap population APIs Muchun Song
2026-11-05 6:12 ` Muchun Song
2026-11-05 7:16 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-198652@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@linux.ibm.com \
--cc=chenhuacai@kernel.org \
--cc=chleroy@kernel.org \
--cc=david@kernel.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kernel@xen0n.name \
--cc=lance.yang@linux.dev \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=muchun.song@linux.dev \
--cc=npiggin@gmail.com \
--cc=osalvador@suse.de \
--cc=qi.zheng@linux.dev \
--cc=ritesh.list@gmail.com \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=songmuchun@bytedance.com \
--cc=sshegde@linux.ibm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.