From: Wei Yang <richard.weiyang@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Wei Yang <richard.weiyang@gmail.com>,
david@kernel.org, ljs@kernel.org, riel@surriel.com,
liam@infradead.org, vbabka@kernel.org, harry@kernel.org,
jannh@google.com, willy@infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, lance.yang@linux.dev,
Kiryl Shutsemau <kas@kernel.org>, Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE
Date: Fri, 4 Sep 2026 02:02:29 +0000 [thread overview]
Message-ID: <20260904020229.etsxwqw74ug7c7hs@master> (raw)
In-Reply-To: <20260902200220.408ae7e8a28d3af4e82fd060@linux-foundation.org>
On Wed, Sep 02, 2026 at 08:02:20PM -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.
>>
>> [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/
>>
>> ...
>>
>> --- 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)
>> {
>
>lgtm, thanks.
>
>You provoked Sashiko into talking about memory corruption and kernel
>panics in page_vma_mapped.c. Usual stuff.
>
> https://sashiko.dev/#/patchset/20260624082359.2869-1-richard.weiyang@gmail.com
>
Hi, Andrew
IIUC, the issue reported by Sashiko is fixed by
commit f84ca9b1888d ("mm/page_vma_mapped: fix device-private PMD handling")
>I'll cc likely suspects but boy do we need a way of being more
>organized about this.
The build error fixed here is introduced by v3 [1], in which check_pmd() is
invoked outside a conditional "if".
Then v4 [2] and v5 [3] call check_pmd() in a conditional "if" and at last
David fix this with IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE).
Do you suggest still conditionally define check_pmd()? I may not follow your
point.
Have a good day.
[1]: https://lore.kernel.org/all/20260622130651.23359-1-richard.weiyang@gmail.com/
[2]: https://lore.kernel.org/all/20260624065353.1622-1-richard.weiyang@gmail.com/T/#u
[3]: https://lore.kernel.org/linux-mm/20260630021540.17297-1-richard.weiyang@gmail.com/
--
Wei Yang
Help you, Help me
prev parent reply other threads:[~2026-09-04 2:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 8:23 [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE Wei Yang
2026-06-24 20:14 ` Andrew Morton
2026-06-25 3:46 ` Wei Yang
2026-06-25 4:59 ` Andrew Morton
2026-06-25 6:41 ` Wei Yang
2026-06-25 13:51 ` Lorenzo Stoakes
2026-06-26 0:08 ` Balbir Singh
2026-06-25 13:45 ` Lorenzo Stoakes
2026-06-25 13:49 ` David Hildenbrand (Arm)
2026-06-25 14:02 ` Lorenzo Stoakes
2026-06-25 14:30 ` David Hildenbrand (Arm)
2026-06-25 16:18 ` Wei Yang
2026-06-25 23:13 ` Wei Yang
2026-09-03 3:02 ` Andrew Morton
2026-09-04 2:02 ` Wei Yang [this message]
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=20260904020229.etsxwqw74ug7c7hs@master \
--to=richard.weiyang@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=harry@kernel.org \
--cc=hughd@google.com \
--cc=jannh@google.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=riel@surriel.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox