From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B9419282F08 for ; Thu, 25 Jun 2026 13:45:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782395134; cv=none; b=mfB8eQt8IoXWqFFsYGAc8Ve2ZF4f3sgbY27jwY+HKK9bkXoR4D935WCUoZVElRM1+ekTj2q0w6SDFKKjy95rwC85l7inOmrQebXMVxC99mNU7XQT9gMWcmN2Wm3du4Sc8M0zDvgd9MbxTAgpzROIxO5udVYCsxvPty5AkzLda9w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782395134; c=relaxed/simple; bh=wk6brN/D98KbHYDMJDi/evS2c2uvzmBX7B6nLuzV58c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BblheV3EbpoOiZMXfcN2F8ZP9yH8PPIa2Pgh4qO4O3aU3HQENArV9hFTaggowDGkyAZJK4j1PMzc2cn/XyrgBVwoUDnpf0jSljgcxRR9MAPJd2gPtX/A9Xh+SWLB9AZsvGxYOCRpPI0iyO6XzXvQjA72Ofi1pXqMK6NObE0U1j8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KGnA5QDG; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KGnA5QDG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA26B1F000E9; Thu, 25 Jun 2026 13:45:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782395133; bh=MQgm/0xUjnC2uKkCTFkFQ7HDUhhiNYBzn6GFhSGt9ZI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=KGnA5QDGaoY8BJI8guQ+6hdBNoRkYIFOa/L7h/05sUKpKoU34O8rde5GdjZFCUkmS 9E4SrxlHnWdbSaKU5ucf+b68LhbnMoGzDpvRju52YFKXh27oMdjhXyIiAwTipo1GU4 HgiZeHTSkVZUIdPbtXPnonok2QjuIvs/lXsZnyRuHkVke2hdzV3waEUNXFRaR0A6iu ToZk5v29H6YT2bQzECzX4SDgRGe2TJYBeZKugFfCYKg7hQZsB0zSD5DJ0/XCGPoc4H IfQvxFcMsVBQ+LglB0e4vr5CFYO1D6eqAwdZXXN3QEPTpHXgKlHW2uqzxZa4QwVefN mTcnp64eDawYg== Date: Thu, 25 Jun 2026 14:45:25 +0100 From: Lorenzo Stoakes To: Wei Yang Cc: akpm@linux-foundation.org, david@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 Subject: Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE Message-ID: References: <20260624082359.2869-1-richard.weiyang@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260624082359.2869-1-richard.weiyang@gmail.com> 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 > Reported-by: kernel test robot > 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