Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Kiryl Shutsemau <kas@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: kernel test robot <lkp@intel.com>,
	oe-kbuild-all@lists.linux.dev,
	 David Hildenbrand <david@kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	 mm-commits@vger.kernel.org
Subject: Re: [akpm-mm:mm-unstable 340/601] include/linux/compiler_types.h:702:38: error: call to '__compiletime_assert_501' declared with attribute error: BUILD_BUG failed
Date: Mon, 27 Jul 2026 10:25:42 +0100	[thread overview]
Message-ID: <amcitKvUvFYr8W38@thinkstation> (raw)
In-Reply-To: <20260725195108.3f31c2641b0689d344e55400@linux-foundation.org>

On Sat, Jul 25, 2026 at 07:51:08PM -0700, Andrew Morton wrote:
> On Sat, 25 Jul 2026 08:56:41 +0800 kernel test robot <lkp@intel.com> wrote:
> 
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable
> > head:   c04df384b55dd9dcf72c36b661becb5aaba371a9
> > commit: d2aed7c02fafacb9d055a2f683ac12e977ef16e0 [340/601] mm: preserve RWP marker across PTE rewrites
> > config: sparc64-randconfig-r134-20260725 (https://download.01.org/0day-ci/archive/20260725/202607250853.VaJWGLeA-lkp@intel.com/config)
> > compiler: sparc64-linux-gcc (GCC) 8.5.0
> > sparse: v0.6.5-rc1
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260725/202607250853.VaJWGLeA-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202607250853.VaJWGLeA-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> >    In file included from <command-line>:
> >    mm/huge_memory.c: In function 'move_pages_huge_pmd':
> > >> include/linux/compiler_types.h:702:38: error: call to '__compiletime_assert_501' declared with attribute error: BUILD_BUG failed
> >      _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> >                                          ^
> >    include/linux/compiler_types.h:683:4: note: in definition of macro '__compiletime_assert'
> >        prefix ## suffix();    \
> 
> Well dang.
> 
> I can't reproduce with sparc64 gcc-15.2.0. 
> Documentation/process/changes.rst says we support 8,1, released in
> 2018.  Your 8.5 was released in 2021 so perhaps three other people are
> still using it :(
> 
> https://www.kernel.org/pub/tools/crosstool/ doesn't appear to have
> sparc64 gcc-8.5 so I gave up.
> 
> So I dunno.  I'm inclined to ignore and assume that if someone else hits
> this one day, they'll either fix it or provide us with enough details
> to figure it out.

I cannot reproduce it either. Maybe we can help compiler to derive that the
code is dead?

-- >8 --
From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
Date: Mon, 27 Jul 2026 10:16:11 +0100
Subject: [PATCH] mm: fold userfaultfd_rwp() to false without
 CONFIG_ARCH_HAS_PTE_PROTNONE

RWP tracks accesses by installing PAGE_NONE (protnone) PTEs, so its code
paths are gated on userfaultfd_rwp(). Without CONFIG_ARCH_HAS_PTE_PROTNONE
there is no PAGE_NONE -- <linux/pgtable.h> defines it to a BUILD_BUG()
stub, relying on callers folding such paths to dead code via
IS_ENABLED(CONFIG_ARCH_HAS_PTE_PROTNONE).

userfaultfd_rwp() was not a compile-time constant, so the compiler could
not fold those paths. With an older compiler (gcc 8.5.0, sparc64) the
PAGE_NONE reference in move_pages_huge_pmd() survived to codegen:

  mm/huge_memory.c:2874: _dst_pmd = pmd_modify(_dst_pmd, PAGE_NONE);
  compiler_types.h:702: error: call to '__compiletime_assert_501'
    declared with attribute error: BUILD_BUG failed

RWP cannot exist without protnone, so return a compile-time false when
CONFIG_ARCH_HAS_PTE_PROTNONE is unset; every RWP path then folds away.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
---
 include/linux/userfaultfd_k.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
index bfbd6a59909f..0ce438ec294f 100644
--- a/include/linux/userfaultfd_k.h
+++ b/include/linux/userfaultfd_k.h
@@ -221,6 +221,12 @@ static inline bool userfaultfd_minor(struct vm_area_struct *vma)
 
 static inline bool userfaultfd_rwp(struct vm_area_struct *vma)
 {
+	/*
+	 * Callers gate PAGE_NONE usage on this; PAGE_NONE is a BUILD_BUG()
+	 * without CONFIG_ARCH_HAS_PTE_PROTNONE, so fold to false.
+	 */
+	if (!IS_ENABLED(CONFIG_ARCH_HAS_PTE_PROTNONE))
+		return false;
 	return vma_test_single_mask(vma, VMA_UFFD_RWP);
 }
 

base-commit: 505f6bc5c6c6db7d6390ea33c4e2ab44379e6f49
-- 
  Kiryl Shutsemau / Kirill A. Shutemov


      reply	other threads:[~2026-07-27  9:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25  0:56 [akpm-mm:mm-unstable 340/601] include/linux/compiler_types.h:702:38: error: call to '__compiletime_assert_501' declared with attribute error: BUILD_BUG failed kernel test robot
2026-07-26  2:51 ` Andrew Morton
2026-07-27  9:25   ` Kiryl Shutsemau [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=amcitKvUvFYr8W38@thinkstation \
    --to=kas@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=mm-commits@vger.kernel.org \
    --cc=oe-kbuild-all@lists.linux.dev \
    /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