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 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.