[PATCH] mm: move phys_mem_access_prot_allowed to header

[PATCH] mm: move phys_mem_access_prot_allowed to header

[Rosen Penev]

phys_mem_access_prot_allowed is only implemented for X86. For others, it
returns 1. Move it to header to avoid using __weak.

Fixes compilation with make LLVM=1 ARCH=mips

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/char/mem.c      | 6 ------
 include/linux/pgtable.h | 8 ++++++++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 5fd421e48c04..ae8449674f46 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -239,12 +239,6 @@ static ssize_t write_mem(struct file *file, const char __user *buf,
 	return written;
 }
 
-int __weak phys_mem_access_prot_allowed(struct file *file,
-	unsigned long pfn, unsigned long size, pgprot_t *vma_prot)
-{
-	return 1;
-}
-
 #ifndef __HAVE_PHYS_MEM_ACCESS_PROT
 
 /*
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index cdd68ed3ae1a..72a7fa388e88 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -2154,8 +2154,16 @@ static inline int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
 #endif
 
 struct file;
+#ifdef CONFIG_X86
 int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
 			unsigned long size, pgprot_t *vma_prot);
+#else
+static inline
+int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
+			unsigned long size, pgprot_t *vma_prot) {
+	return 1;
+}
+#endif
 
 #ifndef CONFIG_X86_ESPFIX64
 static inline void init_espfix_bsp(void) { }
-- 
2.54.0

Re: [PATCH] mm: move phys_mem_access_prot_allowed to header

[Arnd Bergmann]

On Tue, May 5, 2026, at 03:01, Rosen Penev wrote:
> phys_mem_access_prot_allowed is only implemented for X86. For others, it
> returns 1. Move it to header to avoid using __weak.
>
> Fixes compilation with make LLVM=1 ARCH=mips

Can you describe what exactly goes wrong here on mips?

> @@ -239,12 +239,6 @@ static ssize_t write_mem(struct file *file, const 
> char __user *buf,
>  	return written;
>  }
> 
> -int __weak phys_mem_access_prot_allowed(struct file *file,
> -	unsigned long pfn, unsigned long size, pgprot_t *vma_prot)
> -{
> -	return 1;
> -}
> -

Removing __weak functions is usually an improvement, but I think
we can go further here, see the discussion from last year at

https://lore.kernel.org/all/20250520152030.1499670-1-arnd@kernel.org/#t

     Arnd

Re: [PATCH] mm: move phys_mem_access_prot_allowed to header

[Rosen Penev]

On Mon, May 4, 2026 at 10:54 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, May 5, 2026, at 03:01, Rosen Penev wrote:
> > phys_mem_access_prot_allowed is only implemented for X86. For others, it
> > returns 1. Move it to header to avoid using __weak.
> >
> > Fixes compilation with make LLVM=1 ARCH=mips
>
> Can you describe what exactly goes wrong here on mips?
Cannot find symbol for section 4: .text.phys_mem_access_prot_allowed.
drivers/char/mem.o: failed

It's full of similar errors in drivers/pci/ as well. clang on MIPS
doesn't seem to like __weak.
>
> > @@ -239,12 +239,6 @@ static ssize_t write_mem(struct file *file, const
> > char __user *buf,
> >       return written;
> >  }
> >
> > -int __weak phys_mem_access_prot_allowed(struct file *file,
> > -     unsigned long pfn, unsigned long size, pgprot_t *vma_prot)
> > -{
> > -     return 1;
> > -}
> > -
>
> Removing __weak functions is usually an improvement, but I think
> we can go further here, see the discussion from last year at
>
> https://lore.kernel.org/all/20250520152030.1499670-1-arnd@kernel.org/#t
I hold no opinion on that.
>
>      Arnd

Re: [PATCH] mm: move phys_mem_access_prot_allowed to header

[Arnd Bergmann]

On Tue, May 5, 2026, at 09:47, Rosen Penev wrote:
> On Mon, May 4, 2026 at 10:54 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tue, May 5, 2026, at 03:01, Rosen Penev wrote:
>> > phys_mem_access_prot_allowed is only implemented for X86. For others, it
>> > returns 1. Move it to header to avoid using __weak.
>> >
>> > Fixes compilation with make LLVM=1 ARCH=mips
>>
>> Can you describe what exactly goes wrong here on mips?
> Cannot find symbol for section 4: .text.phys_mem_access_prot_allowed.
> drivers/char/mem.o: failed
>
> It's full of similar errors in drivers/pci/ as well. clang on MIPS
> doesn't seem to like __weak.

This certainly feels like a toolchain bug. I would not mind having
the PCI code converted away from the __weak functions, but it should
not just fail with a linker error like this.

Does this happen with both ld.bfd and ld.lld? Which version of clang
and lld are you using? 

      Arnd

Re: [PATCH] mm: move phys_mem_access_prot_allowed to header

[Rosen Penev]

On Tue, May 5, 2026 at 1:29 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, May 5, 2026, at 09:47, Rosen Penev wrote:
> > On Mon, May 4, 2026 at 10:54 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> On Tue, May 5, 2026, at 03:01, Rosen Penev wrote:
> >> > phys_mem_access_prot_allowed is only implemented for X86. For others, it
> >> > returns 1. Move it to header to avoid using __weak.
> >> >
> >> > Fixes compilation with make LLVM=1 ARCH=mips
> >>
> >> Can you describe what exactly goes wrong here on mips?
> > Cannot find symbol for section 4: .text.phys_mem_access_prot_allowed.
> > drivers/char/mem.o: failed
> >
> > It's full of similar errors in drivers/pci/ as well. clang on MIPS
> > doesn't seem to like __weak.
>
> This certainly feels like a toolchain bug. I would not mind having
> the PCI code converted away from the __weak functions, but it should
> not just fail with a linker error like this.
FWIW I just tested

make LLVM=1 ARCH=powerpc -j 31

which results in no such errors. So probably.
>
> Does this happen with both ld.bfd and ld.lld? Which version of clang
> and lld are you using?
clang version 22.1.3
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

lld the same.

I don't specify lld explicitly. I assume LLVM=1 does that.
>
>       Arnd

Re: [PATCH] mm: move phys_mem_access_prot_allowed to header

[Arnd Bergmann]

On Tue, May 5, 2026, at 10:54, Rosen Penev wrote:
> On Tue, May 5, 2026 at 1:29 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> Does this happen with both ld.bfd and ld.lld? Which version of clang
>> and lld are you using?
> clang version 22.1.3
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
>
> lld the same.

Ok. I've tried to reproduce this with Nathan's llvm-22.1.3 build
from https://mirrors.edge.kernel.org/pub/tools/llvm/, but don't
see this problem on mips defconfig. Are you using a particular
configuration, or do you see this on every build?

> I don't specify lld explicitly. I assume LLVM=1 does that.

Yes, by default it will use ld.lld. For cross-checking, you
can try passing LD=mips-linux-ld.bfd (or whereever you have
installed your cross or multiarch binutils), which should
still work just fine.

       Arnd

Re: [PATCH] mm: move phys_mem_access_prot_allowed to header

[Rosen Penev]

On Tue, May 5, 2026 at 2:23 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, May 5, 2026, at 10:54, Rosen Penev wrote:
> > On Tue, May 5, 2026 at 1:29 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> Does this happen with both ld.bfd and ld.lld? Which version of clang
> >> and lld are you using?
> > clang version 22.1.3
> > Target: x86_64-pc-linux-gnu
> > Thread model: posix
> > InstalledDir: /usr/bin
> >
> > lld the same.
>
> Ok. I've tried to reproduce this with Nathan's llvm-22.1.3 build
> from https://mirrors.edge.kernel.org/pub/tools/llvm/, but don't
> see this problem on mips defconfig. Are you using a particular
> configuration, or do you see this on every build?
I use allmodconfig. And yes, every build. I'm using a fully updated Arch Linux.
>
> > I don't specify lld explicitly. I assume LLVM=1 does that.
>
> Yes, by default it will use ld.lld. For cross-checking, you
> can try passing LD=mips-linux-ld.bfd (or whereever you have
> installed your cross or multiarch binutils), which should
> still work just fine.
Arch seems to not provide such a thing.
>
>        Arnd

Re: [PATCH] mm: move phys_mem_access_prot_allowed to header

[Nathan Chancellor]

On Tue, May 05, 2026 at 11:22:13AM +0200, Arnd Bergmann wrote:
> On Tue, May 5, 2026, at 10:54, Rosen Penev wrote:
> > On Tue, May 5, 2026 at 1:29 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> Does this happen with both ld.bfd and ld.lld? Which version of clang
> >> and lld are you using?
> > clang version 22.1.3
> > Target: x86_64-pc-linux-gnu
> > Thread model: posix
> > InstalledDir: /usr/bin
> >
> > lld the same.
> 
> Ok. I've tried to reproduce this with Nathan's llvm-22.1.3 build
> from https://mirrors.edge.kernel.org/pub/tools/llvm/, but don't
> see this problem on mips defconfig. Are you using a particular
> configuration, or do you see this on every build?

This is just the same old integrated assembler vs. recordmcount bug:

  https://github.com/ClangBuiltLinux/linux/issues/981
  https://github.com/ClangBuiltLinux/linux/issues/1830

It requires CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y with ftrace, which
MIPS allmodconfig enables. PowerPC worked around this in commit
f8b2336f15f3 ("powerpc: Avoid dead code/data elimination when using
recordmcount"). Maybe something along the same lines should be done for
MIPS.

Cheers,
Nathan

Re: [PATCH] mm: move phys_mem_access_prot_allowed to header

[Rosen Penev]

On Tue, May 5, 2026 at 10:48 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Tue, May 05, 2026 at 11:22:13AM +0200, Arnd Bergmann wrote:
> > On Tue, May 5, 2026, at 10:54, Rosen Penev wrote:
> > > On Tue, May 5, 2026 at 1:29 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >>
> > >> Does this happen with both ld.bfd and ld.lld? Which version of clang
> > >> and lld are you using?
> > > clang version 22.1.3
> > > Target: x86_64-pc-linux-gnu
> > > Thread model: posix
> > > InstalledDir: /usr/bin
> > >
> > > lld the same.
> >
> > Ok. I've tried to reproduce this with Nathan's llvm-22.1.3 build
> > from https://mirrors.edge.kernel.org/pub/tools/llvm/, but don't
> > see this problem on mips defconfig. Are you using a particular
> > configuration, or do you see this on every build?
>
> This is just the same old integrated assembler vs. recordmcount bug:
>
>   https://github.com/ClangBuiltLinux/linux/issues/981
>   https://github.com/ClangBuiltLinux/linux/issues/1830
>
> It requires CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y with ftrace, which
> MIPS allmodconfig enables. PowerPC worked around this in commit
> f8b2336f15f3 ("powerpc: Avoid dead code/data elimination when using
> recordmcount"). Maybe something along the same lines should be done for
> MIPS.
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -82,7 +82,7 @@ config MIPS
        select HAVE_IRQ_TIME_ACCOUNTING
        select HAVE_KPROBES
        select HAVE_KRETPROBES
-       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
+       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if HAVE_OBJTOOL_MCOUNT
        select HAVE_MOD_ARCH_SPECIFIC
        select HAVE_NMI
        select HAVE_PAGE_SIZE_4KB if !CPU_LOONGSON2EF && !CPU_LOONGSON64

fixes it. I see master has a different line for powerpc. I defer to
the experts on this.
>
> Cheers,
> Nathan