[PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[Wei Yang]

The kernel test robot reported a build failure on the parisc architecture
when expanding HPAGE_PMD_NR in check_pmd().

   mm/page_vma_mapped.c:142:13: note: in expansion of macro 'HPAGE_PMD_NR'
     if ((pfn + HPAGE_PMD_NR - 1) < pvmw->pfn)
                ^~~~~~~~~~~~

The config [1] in report link shows neither TRANSPARENT_HUGEPAGE nor
HUGETLB_PAGE is defined. Then trigger the BUILD_BUG.

Fix it by define check_pmd() under CONFIG_TRANSPARENT_HUGEPAGE.

[1]: https://download.01.org/0day-ci/archive/20260624/202606240042.ffPsEXVc-lkp@intel.com/config

Fixes: 2aff7a4755be ("mm: Convert page_vma_mapped_walk to work on PFNs")
Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202606240042.ffPsEXVc-lkp@intel.com/
---
 mm/page_vma_mapped.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
index 17dff8aab9f9..4aac94d9e8a9 100644
--- a/mm/page_vma_mapped.c
+++ b/mm/page_vma_mapped.c
@@ -136,6 +136,7 @@ static bool check_pte(struct page_vma_mapped_walk *pvmw, unsigned long pte_nr)
 	return true;
 }
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 /* Returns true if the two ranges overlap.  Careful to not overflow. */
 static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
 {
@@ -145,6 +146,12 @@ static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
 		return false;
 	return true;
 }
+#else
+static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
+{
+	return false;
+}
+#endif
 
 static void step_forward(struct page_vma_mapped_walk *pvmw, unsigned long size)
 {
-- 
2.34.1

Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[Andrew Morton]

On Wed, 24 Jun 2026 08:23:59 +0000 Wei Yang <richard.weiyang@gmail.com> wrote:

> The kernel test robot reported a build failure on the parisc architecture
> when expanding HPAGE_PMD_NR in check_pmd().
> 
>    mm/page_vma_mapped.c:142:13: note: in expansion of macro 'HPAGE_PMD_NR'
>      if ((pfn + HPAGE_PMD_NR - 1) < pvmw->pfn)
>                 ^~~~~~~~~~~~
> 
> The config [1] in report link shows neither TRANSPARENT_HUGEPAGE nor
> HUGETLB_PAGE is defined. Then trigger the BUILD_BUG.
> 
> Fix it by define check_pmd() under CONFIG_TRANSPARENT_HUGEPAGE.

hm,

#ifdef CONFIG_PGTABLE_HAS_HUGE_LEAVES
#define HPAGE_PMD_SHIFT PMD_SHIFT
#define HPAGE_PUD_SHIFT PUD_SHIFT
#else
#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
#define HPAGE_PUD_SHIFT ({ BUILD_BUG(); 0; })
#endif

> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  /* Returns true if the two ranges overlap.  Careful to not overflow. */
>  static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
>  {
> @@ -145,6 +146,12 @@ static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
>  		return false;
>  	return true;
>  }
> +#else
> +static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
> +{
> +	return false;
> +}
> +#endif

I'll leave it to others to decide if this is the most appropriate fix.

Sashiko had an off-topic complaint about the surrounding code:
	https://lore.kernel.org/oe-kbuild-all/202606240042.ffPsEXVc-lkp@intel.com/

Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[Wei Yang]

On Wed, Jun 24, 2026 at 01:14:57PM -0700, Andrew Morton wrote:
>On Wed, 24 Jun 2026 08:23:59 +0000 Wei Yang <richard.weiyang@gmail.com> wrote:
>
>> The kernel test robot reported a build failure on the parisc architecture
>> when expanding HPAGE_PMD_NR in check_pmd().
>> 
>>    mm/page_vma_mapped.c:142:13: note: in expansion of macro 'HPAGE_PMD_NR'
>>      if ((pfn + HPAGE_PMD_NR - 1) < pvmw->pfn)
>>                 ^~~~~~~~~~~~
>> 
>> The config [1] in report link shows neither TRANSPARENT_HUGEPAGE nor
>> HUGETLB_PAGE is defined. Then trigger the BUILD_BUG.
>> 
>> Fix it by define check_pmd() under CONFIG_TRANSPARENT_HUGEPAGE.
>
>hm,
>
>#ifdef CONFIG_PGTABLE_HAS_HUGE_LEAVES
>#define HPAGE_PMD_SHIFT PMD_SHIFT
>#define HPAGE_PUD_SHIFT PUD_SHIFT
>#else
>#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
>#define HPAGE_PUD_SHIFT ({ BUILD_BUG(); 0; })
>#endif
>
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>  /* Returns true if the two ranges overlap.  Careful to not overflow. */
>>  static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
>>  {
>> @@ -145,6 +146,12 @@ static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
>>  		return false;
>>  	return true;
>>  }
>> +#else
>> +static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
>> +{
>> +	return false;
>> +}
>> +#endif
>
>I'll leave it to others to decide if this is the most appropriate fix.
>
>Sashiko had an off-topic complaint about the surrounding code:
>	https://lore.kernel.org/oe-kbuild-all/202606240042.ffPsEXVc-lkp@intel.com/

I see this robot reply, but not see the Sashiko comment.

How can I view Sashiko's commnet?

-- 
Wei Yang
Help you, Help me

Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[Andrew Morton]

On Thu, 25 Jun 2026 03:46:29 +0000 Wei Yang <richard.weiyang@gmail.com> wrote:

> >Sashiko had an off-topic complaint about the surrounding code:
> >	https://lore.kernel.org/oe-kbuild-all/202606240042.ffPsEXVc-lkp@intel.com/
> 
> I see this robot reply, but not see the Sashiko comment.
> 
> How can I view Sashiko's commnet?

oop sorry.

You can go to https://sashiko.dev/ and search for the email subject. 

Or append your Message-ID to "https://sashiko.dev/#/patchset":

	https://sashiko.dev/#/patchset/20260624082359.2869-1-richard.weiyang@gmail.com

Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[Wei Yang]

+cc Balbir

On Wed, Jun 24, 2026 at 09:59:43PM -0700, Andrew Morton wrote:
>On Thu, 25 Jun 2026 03:46:29 +0000 Wei Yang <richard.weiyang@gmail.com> wrote:
>
>> >Sashiko had an off-topic complaint about the surrounding code:
>> >	https://lore.kernel.org/oe-kbuild-all/202606240042.ffPsEXVc-lkp@intel.com/
>> 
>> I see this robot reply, but not see the Sashiko comment.
>> 
>> How can I view Sashiko's commnet?
>
>oop sorry.
>
>You can go to https://sashiko.dev/ and search for the email subject. 
>
>Or append your Message-ID to "https://sashiko.dev/#/patchset":
>
>	https://sashiko.dev/#/patchset/20260624082359.2869-1-richard.weiyang@gmail.com
>

Got it, thansk

This one mentioned two things:

  a. page_vma_mapped_walk() return without check
  b. whether __split_huge_pmd_locked() would split device-private pmd

For a., it is being fixing at [1].

For b., to be honest I am not 100% for sure. If a device-private pmd could be
file backed, then this looks like a bug.

Balbir,

Would you mind taking a look at the second comment raised by Sashiko?

[1]: https://lore.kernel.org/linux-mm/20260624065353.1622-1-richard.weiyang@gmail.com/

-- 
Wei Yang
Help you, Help me

Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[Lorenzo Stoakes]

+cc Roman for Sashiko discussion

On Thu, Jun 25, 2026 at 06:41:02AM +0000, Wei Yang wrote:
> +cc Balbir
>
> On Wed, Jun 24, 2026 at 09:59:43PM -0700, Andrew Morton wrote:
> >On Thu, 25 Jun 2026 03:46:29 +0000 Wei Yang <richard.weiyang@gmail.com> wrote:
> >
> >> >Sashiko had an off-topic complaint about the surrounding code:
> >> >	https://lore.kernel.org/oe-kbuild-all/202606240042.ffPsEXVc-lkp@intel.com/
> >>
> >> I see this robot reply, but not see the Sashiko comment.
> >>
> >> How can I view Sashiko's commnet?
> >
> >oop sorry.
> >
> >You can go to https://sashiko.dev/ and search for the email subject.
> >
> >Or append your Message-ID to "https://sashiko.dev/#/patchset":
> >
> >	https://sashiko.dev/#/patchset/20260624082359.2869-1-richard.weiyang@gmail.com
> >
>
> Got it, thansk
>
> This one mentioned two things:
>
>   a. page_vma_mapped_walk() return without check
>   b. whether __split_huge_pmd_locked() would split device-private pmd
>
> For a., it is being fixing at [1].
>
> For b., to be honest I am not 100% for sure. If a device-private pmd could be
> file backed, then this looks like a bug.
>
> Balbir,
>
> Would you mind taking a look at the second comment raised by Sashiko?
>
> [1]: https://lore.kernel.org/linux-mm/20260624065353.1622-1-richard.weiyang@gmail.com/

I continue to dislike that sashiko does this.

Series with... interesting use of AI :).. are already taking up more of the time
we reviewers don't have... but interrupting existing review to mention random
stuff is unhelpful I feel :)

I think the better use of time here would be for Balbir to perhaps ask AI to
examine all cases where a PMD device private entry might crop up and to check to
see if there's any other bugs similar to the ones we've encountered before?

Given Sashiko is very token-constrained, I also wonder whether this feature
wouldn't be better disabled (or maybe have the ability to turn off
per-subsystem?)

In a couple other cases the 'also consider' stuff actually took a bunch of time
unnecessarily and I felt they interferred with the series landing.

Given the time constraints we all work under, it'd be better not to add to
workload this way (having to figure out if the points are valid are a time drain
in themselves).

Thanks, Lorenzo

Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[Lorenzo Stoakes]

On Wed, Jun 24, 2026 at 08:23:59AM +0000, Wei Yang wrote:
> The kernel test robot reported a build failure on the parisc architecture
> when expanding HPAGE_PMD_NR in check_pmd().

Let me first say that I absolutely hate that we continue to support museum
piece architectures to the point that we have to make changes in core code
to accommodate them.

It's not unreasonable to ask retro people to either use older kernels or
make a downstream fork.

People having to think about this upstream is so incredibly silly. As if we
don't have enough work already...

Anyway, with that said...

>
>    mm/page_vma_mapped.c:142:13: note: in expansion of macro 'HPAGE_PMD_NR'
>      if ((pfn + HPAGE_PMD_NR - 1) < pvmw->pfn)
>                 ^~~~~~~~~~~~
>
> The config [1] in report link shows neither TRANSPARENT_HUGEPAGE nor
> HUGETLB_PAGE is defined. Then trigger the BUILD_BUG.
>
> Fix it by define check_pmd() under CONFIG_TRANSPARENT_HUGEPAGE.
>
> [1]: https://download.01.org/0day-ci/archive/20260624/202606240042.ffPsEXVc-lkp@intel.com/config

I think the fact this wasn't detected for 4 odd years goes to show how well
tested stuff on this arch is... (unless this is a very unusual
configuration at least).

>
> Fixes: 2aff7a4755be ("mm: Convert page_vma_mapped_walk to work on PFNs")
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606240042.ffPsEXVc-lkp@intel.com/
> ---
>  mm/page_vma_mapped.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
> index 17dff8aab9f9..4aac94d9e8a9 100644
> --- a/mm/page_vma_mapped.c
> +++ b/mm/page_vma_mapped.c
> @@ -136,6 +136,7 @@ static bool check_pte(struct page_vma_mapped_walk *pvmw, unsigned long pte_nr)
>  	return true;
>  }
>
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE

As per Andrew, this should be CONFIG_PGTABLE_HAS_HUGE_LEAVES I think.

I don't like that CONFIG_T..HP is taken to mean 'anything to do with leaf
page tables'. That's a mess and one we should unwind.

So don't make it worse, use CONFIG_PGTABLE_HAS_HUGE_LEAVES.

>  /* Returns true if the two ranges overlap.  Careful to not overflow. */
>  static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
>  {
> @@ -145,6 +146,12 @@ static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
>  		return false;
>  	return true;
>  }
> +#else
> +static bool check_pmd(unsigned long pfn, struct page_vma_mapped_walk *pvmw)
> +{
> +	return false;

Should have a WARN_ON_ONCE("bug in stupid arch") or similar here ;)

> +}
> +#endif
>
>  static void step_forward(struct page_vma_mapped_walk *pvmw, unsigned long size)
>  {
> --
> 2.34.1
>

Thanks, Lorenzo

Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[David Hildenbrand (Arm)]

On 6/25/26 15:45, Lorenzo Stoakes wrote:
> On Wed, Jun 24, 2026 at 08:23:59AM +0000, Wei Yang wrote:
>> The kernel test robot reported a build failure on the parisc architecture
>> when expanding HPAGE_PMD_NR in check_pmd().
> 
> Let me first say that I absolutely hate that we continue to support museum
> piece architectures to the point that we have to make changes in core code
> to accommodate them.

I wonder why we shouldn't be able to trigger that on other archs with
!CONFIG_TRANSPARENT_HUGEPAGE ?

I think the code just relies on pmd_trans_huge() == false, and consequently
check_pmd will get compiled out completely.

Now, the report was against Wei's new patch.

There is *nothing* to be fixed for existing code.


Fixes: 2aff7a4755be ("mm: Convert page_vma_mapped_walk to work on PFNs")

is just wrong?

-- 
Cheers,

David