Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
On 3/28/24 00:15, Mike Rapoport wrote: > On Thu, Mar 28, 2024 at 07:09:13AM +0100, Arnd Bergmann wrote: >> On Thu, Mar 28, 2024, at 06:51, Vineet Gupta wrote: >>> On 3/27/24 09:22, Arnd Bergmann wrote: On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote: > On 27.03.24 16:21, Peter Xu wrote: >> On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote: >> >> I'm not sure what config you tried there; as I am doing some build tests >> recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could >> avoid a lot of issues, I think it's due to libc missing. But maybe not >> the >> case there. > CCin Arnd; I use some of his compiler chains, others from Fedora > directly. For > example for alpha and arc, the Fedora gcc is "13.2.1". > But there is other stuff like (arc): > > ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid': > ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of > function 'write_aux_reg' [-Werro > r=implicit-function-declaration] > 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE); >| ^ Seems to be missing an #include of soc/arc/aux.h, but I can't tell when this first broke without bisecting. >>> Weird I don't see this one but I only have gcc 12 handy ATM. >>> >>> gcc version 12.2.1 20230306 (ARC HS GNU/Linux glibc toolchain - >>> build 1360) >>> >>> I even tried W=1 (which according to scripts/Makefile.extrawarn) should >>> include -Werror=implicit-function-declaration but don't see this still. >>> >>> Tomorrow I'll try building a gcc 13.2.1 for ARC. >> David reported them with the toolchains I built at >> https://mirrors.edge.kernel.org/pub/tools/crosstool/ >> I'm fairly sure the problem is specific to the .config >> and tree, not the toolchain though. > This happens with defconfig and both gcc 12.2.0 and gcc 13.2.0 from your > crosstools. I also see these on the current Linus' tree: > > arc/kernel/ptrace.c:342:16: warning: no previous prototype for > 'syscall_trace_enter' [-Wmissing-prototypes] > arch/arc/kernel/kprobes.c:193:15: warning: no previous prototype for > 'arc_kprobe_handler' [-Wmissing-prototypes] Yep these two I could trigger and fix posted [1] > This fixed the warning about write_aux_reg for me, probably Vineet would > want this include somewhere else... > > diff --git a/arch/arc/include/asm/mmu-arcv2.h > b/arch/arc/include/asm/mmu-arcv2.h > index ed9036d4ede3..0fca342d7b79 100644 > --- a/arch/arc/include/asm/mmu-arcv2.h > +++ b/arch/arc/include/asm/mmu-arcv2.h > @@ -69,6 +69,8 @@ > > #ifndef __ASSEMBLY__ > > +#include > + > struct mm_struct; > extern int pae40_exist_but_not_enab(void); Thx Mike. Indeed the fix is trivial but on tip of tree I still can't trigger the warning to even test anything. I'm at following with my other fixes. 2024-03-27 962490525cff Merge tag 'probes-fixes-v6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace I tried defconfig build as well as the exact config from Linaro report [2], and/or various toolchains: from snps github, Arnd's crosstool toolchain. Granted all of these are linux toolchains - I vaguely remember at some time, baremetal elf32 toolchain behaved differently due to different defaults etc. I have a feeling this was something transient which got fixed up due to order of header includes etc. Anyone in the followup email David only reported 2 warnings which have been tended to as mentioned above - will be sent to Linus soon. [1] http://lists.infradead.org/pipermail/linux-snps-arc/2024-March/007916.html [2] https://storage.tuxsuite.com/public/linaro/lkft/builds/2eA2VSZdDsL0DMBBhjoauN9IVoK/ Thx, -Vineet
Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
On 28.03.24 08:15, Mike Rapoport wrote: On Thu, Mar 28, 2024 at 07:09:13AM +0100, Arnd Bergmann wrote: On Thu, Mar 28, 2024, at 06:51, Vineet Gupta wrote: On 3/27/24 09:22, Arnd Bergmann wrote: On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote: On 27.03.24 16:21, Peter Xu wrote: On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote: I'm not sure what config you tried there; as I am doing some build tests recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could avoid a lot of issues, I think it's due to libc missing. But maybe not the case there. CCin Arnd; I use some of his compiler chains, others from Fedora directly. For example for alpha and arc, the Fedora gcc is "13.2.1". But there is other stuff like (arc): ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid': ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of function 'write_aux_reg' [-Werro r=implicit-function-declaration] 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE); | ^ Seems to be missing an #include of soc/arc/aux.h, but I can't tell when this first broke without bisecting. Weird I don't see this one but I only have gcc 12 handy ATM. gcc version 12.2.1 20230306 (ARC HS GNU/Linux glibc toolchain - build 1360) I even tried W=1 (which according to scripts/Makefile.extrawarn) should include -Werror=implicit-function-declaration but don't see this still. Tomorrow I'll try building a gcc 13.2.1 for ARC. David reported them with the toolchains I built at https://mirrors.edge.kernel.org/pub/tools/crosstool/ I'm fairly sure the problem is specific to the .config and tree, not the toolchain though. This happens with defconfig and both gcc 12.2.0 and gcc 13.2.0 from your crosstools. I also see these on the current Linus' tree: arc/kernel/ptrace.c:342:16: warning: no previous prototype for 'syscall_trace_enter' [-Wmissing-prototypes] arch/arc/kernel/kprobes.c:193:15: warning: no previous prototype for 'arc_kprobe_handler' [-Wmissing-prototypes] This fixed the warning about write_aux_reg for me, probably Vineet would want this include somewhere else... diff --git a/arch/arc/include/asm/mmu-arcv2.h b/arch/arc/include/asm/mmu-arcv2.h index ed9036d4ede3..0fca342d7b79 100644 --- a/arch/arc/include/asm/mmu-arcv2.h +++ b/arch/arc/include/asm/mmu-arcv2.h @@ -69,6 +69,8 @@ #ifndef __ASSEMBLY__ +#include + struct mm_struct; extern int pae40_exist_but_not_enab(void); Here are all err+warn I see with my configs on Linus' tree from today (not mm-unstable). Most of them are warnings due to missing prototypes or missing "clone3". Parisc64 seems to be a bit more broken. Maybe nobody cares about parisc64 anymore? Or it's a toolchain issue, don't know. xtensa is also broken, but "invalid register" smells like a toolchain issue to me. Maybe all known/expected, just posting it if anybody cares. I can share my full build script on request. [INFO] Compiling alpha [INFO] 0 errors [INFO] 102 warnings [PASS] $ cat alpha_log | grep warn :1519:2: warning: #warning syscall clone3 not implemented [-Wcpp] arch/alpha/lib/checksum.c:45:9: warning: no previous prototype for 'csum_tcpudp_magic' [-Wmissing-prototypes] arch/alpha/lib/checksum.c:54:8: warning: no previous prototype for 'csum_tcpudp_nofold' [-Wmissing-prototypes] arch/alpha/lib/checksum.c:145:9: warning: no previous prototype for 'ip_fast_csum' [-Wmissing-prototypes] arch/alpha/lib/checksum.c:163:8: warning: no previous prototype for 'csum_partial' [-Wmissing-prototypes] arch/alpha/lib/checksum.c:180:9: warning: no previous prototype for 'ip_compute_csum' [-Wmissing-prototypes] arch/alpha/kernel/traps.c:211:1: warning: no previous prototype for 'do_entArith' [-Wmissing-prototypes] arch/alpha/kernel/traps.c:233:1: warning: no previous prototype for 'do_entIF' [-Wmissing-prototypes] arch/alpha/kernel/traps.c:400:1: warning: no previous prototype for 'do_entDbg' [-Wmissing-prototypes] arch/alpha/kernel/traps.c:436:1: warning: no previous prototype for 'do_entUna' [-Wmissing-prototypes] arch/alpha/kernel/traps.c:721:1: warning: no previous prototype for 'do_entUnaUser' [-Wmissing-prototypes] arch/alpha/mm/init.c:261:1: warning: no previous prototype for 'srm_paging_stop' [-Wmissing-prototypes] arch/alpha/lib/fpreg.c:20:1: warning: no previous prototype for 'alpha_read_fp_reg' [-Wmissing-prototypes] [] [INFO] Compiling arc [INFO] 0 errors [INFO] 2 warnings [PASS] $ cat arc_log | grep warn arch/arc/kernel/ptrace.c:342:16: warning: no previous prototype for 'syscall_trace_enter' [-Wmissing-prototypes] arch/arc/kernel/kprobes.c:193:15: warning: no previous prototype for 'arc_kprobe_handler' [-Wmissing-prototypes] [INFO] Compiling hexagon [INFO] 0 errors [INFO] 1 warnings [PASS] $ cat hexagon_log | grep warn :1519:2: warning: syscall clone3 not implemented [-W#warnings] 1519 | #warning syscall clone3 not implemented 1 warning generated.
Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
On Thu, Mar 28, 2024 at 07:09:13AM +0100, Arnd Bergmann wrote: > On Thu, Mar 28, 2024, at 06:51, Vineet Gupta wrote: > > On 3/27/24 09:22, Arnd Bergmann wrote: > >> On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote: > >>> On 27.03.24 16:21, Peter Xu wrote: > On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote: > > I'm not sure what config you tried there; as I am doing some build tests > recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could > avoid a lot of issues, I think it's due to libc missing. But maybe not > the > case there. > >>> CCin Arnd; I use some of his compiler chains, others from Fedora > >>> directly. For > >>> example for alpha and arc, the Fedora gcc is "13.2.1". > >>> But there is other stuff like (arc): > >>> > >>> ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid': > >>> ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of > >>> function 'write_aux_reg' [-Werro > >>> r=implicit-function-declaration] > >>> 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE); > >>>| ^ > >> Seems to be missing an #include of soc/arc/aux.h, but I can't > >> tell when this first broke without bisecting. > > > > Weird I don't see this one but I only have gcc 12 handy ATM. > > > > gcc version 12.2.1 20230306 (ARC HS GNU/Linux glibc toolchain - > > build 1360) > > > > I even tried W=1 (which according to scripts/Makefile.extrawarn) should > > include -Werror=implicit-function-declaration but don't see this still. > > > > Tomorrow I'll try building a gcc 13.2.1 for ARC. > > David reported them with the toolchains I built at > https://mirrors.edge.kernel.org/pub/tools/crosstool/ > I'm fairly sure the problem is specific to the .config > and tree, not the toolchain though. This happens with defconfig and both gcc 12.2.0 and gcc 13.2.0 from your crosstools. I also see these on the current Linus' tree: arc/kernel/ptrace.c:342:16: warning: no previous prototype for 'syscall_trace_enter' [-Wmissing-prototypes] arch/arc/kernel/kprobes.c:193:15: warning: no previous prototype for 'arc_kprobe_handler' [-Wmissing-prototypes] This fixed the warning about write_aux_reg for me, probably Vineet would want this include somewhere else... diff --git a/arch/arc/include/asm/mmu-arcv2.h b/arch/arc/include/asm/mmu-arcv2.h index ed9036d4ede3..0fca342d7b79 100644 --- a/arch/arc/include/asm/mmu-arcv2.h +++ b/arch/arc/include/asm/mmu-arcv2.h @@ -69,6 +69,8 @@ #ifndef __ASSEMBLY__ +#include + struct mm_struct; extern int pae40_exist_but_not_enab(void); > >>> or (alpha) > >>> > >>> WARNING: modpost: "saved_config" [vmlinux] is COMMON symbol > >>> ERROR: modpost: "memcpy" [fs/reiserfs/reiserfs.ko] undefined! > >>> ERROR: modpost: "memcpy" [fs/nfs/nfs.ko] undefined! > >>> ERROR: modpost: "memcpy" [fs/nfs/nfsv3.ko] undefined! > >>> ERROR: modpost: "memcpy" [fs/nfsd/nfsd.ko] undefined! > >>> ERROR: modpost: "memcpy" [fs/lockd/lockd.ko] undefined! > >>> ERROR: modpost: "memcpy" [crypto/crypto.ko] undefined! > >>> ERROR: modpost: "memcpy" [crypto/crypto_algapi.ko] undefined! > >>> ERROR: modpost: "memcpy" [crypto/aead.ko] undefined! > >>> ERROR: modpost: "memcpy" [crypto/crypto_skcipher.ko] undefined! > >>> ERROR: modpost: "memcpy" [crypto/seqiv.ko] undefined! > > > > Are these from ARC build or otherwise ? > > This was arch/alpha. > > Arnd -- Sincerely yours, Mike.
Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
On Thu, Mar 28, 2024, at 06:51, Vineet Gupta wrote: > On 3/27/24 09:22, Arnd Bergmann wrote: >> On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote: >>> On 27.03.24 16:21, Peter Xu wrote: On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote: I'm not sure what config you tried there; as I am doing some build tests recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could avoid a lot of issues, I think it's due to libc missing. But maybe not the case there. >>> CCin Arnd; I use some of his compiler chains, others from Fedora directly. >>> For >>> example for alpha and arc, the Fedora gcc is "13.2.1". >>> But there is other stuff like (arc): >>> >>> ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid': >>> ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of >>> function 'write_aux_reg' [-Werro >>> r=implicit-function-declaration] >>> 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE); >>>| ^ >> Seems to be missing an #include of soc/arc/aux.h, but I can't >> tell when this first broke without bisecting. > > Weird I don't see this one but I only have gcc 12 handy ATM. > > gcc version 12.2.1 20230306 (ARC HS GNU/Linux glibc toolchain - > build 1360) > > I even tried W=1 (which according to scripts/Makefile.extrawarn) should > include -Werror=implicit-function-declaration but don't see this still. > > Tomorrow I'll try building a gcc 13.2.1 for ARC. David reported them with the toolchains I built at https://mirrors.edge.kernel.org/pub/tools/crosstool/ I'm fairly sure the problem is specific to the .config and tree, not the toolchain though. >>> or (alpha) >>> >>> WARNING: modpost: "saved_config" [vmlinux] is COMMON symbol >>> ERROR: modpost: "memcpy" [fs/reiserfs/reiserfs.ko] undefined! >>> ERROR: modpost: "memcpy" [fs/nfs/nfs.ko] undefined! >>> ERROR: modpost: "memcpy" [fs/nfs/nfsv3.ko] undefined! >>> ERROR: modpost: "memcpy" [fs/nfsd/nfsd.ko] undefined! >>> ERROR: modpost: "memcpy" [fs/lockd/lockd.ko] undefined! >>> ERROR: modpost: "memcpy" [crypto/crypto.ko] undefined! >>> ERROR: modpost: "memcpy" [crypto/crypto_algapi.ko] undefined! >>> ERROR: modpost: "memcpy" [crypto/aead.ko] undefined! >>> ERROR: modpost: "memcpy" [crypto/crypto_skcipher.ko] undefined! >>> ERROR: modpost: "memcpy" [crypto/seqiv.ko] undefined! > > Are these from ARC build or otherwise ? This was arch/alpha. Arnd
Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
+CC Alexey On 3/27/24 09:22, Arnd Bergmann wrote: > On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote: >> On 27.03.24 16:21, Peter Xu wrote: >>> On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote: >>> >>> I'm not sure what config you tried there; as I am doing some build tests >>> recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could >>> avoid a lot of issues, I think it's due to libc missing. But maybe not the >>> case there. >> CCin Arnd; I use some of his compiler chains, others from Fedora directly. >> For >> example for alpha and arc, the Fedora gcc is "13.2.1". >> But there is other stuff like (arc): >> >> ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid': >> ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of >> function 'write_aux_reg' [-Werro >> r=implicit-function-declaration] >> 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE); >>| ^ > Seems to be missing an #include of soc/arc/aux.h, but I can't > tell when this first broke without bisecting. Weird I don't see this one but I only have gcc 12 handy ATM. gcc version 12.2.1 20230306 (ARC HS GNU/Linux glibc toolchain - build 1360) I even tried W=1 (which according to scripts/Makefile.extrawarn) should include -Werror=implicit-function-declaration but don't see this still. Tomorrow I'll try building a gcc 13.2.1 for ARC. > >> or (alpha) >> >> WARNING: modpost: "saved_config" [vmlinux] is COMMON symbol >> ERROR: modpost: "memcpy" [fs/reiserfs/reiserfs.ko] undefined! >> ERROR: modpost: "memcpy" [fs/nfs/nfs.ko] undefined! >> ERROR: modpost: "memcpy" [fs/nfs/nfsv3.ko] undefined! >> ERROR: modpost: "memcpy" [fs/nfsd/nfsd.ko] undefined! >> ERROR: modpost: "memcpy" [fs/lockd/lockd.ko] undefined! >> ERROR: modpost: "memcpy" [crypto/crypto.ko] undefined! >> ERROR: modpost: "memcpy" [crypto/crypto_algapi.ko] undefined! >> ERROR: modpost: "memcpy" [crypto/aead.ko] undefined! >> ERROR: modpost: "memcpy" [crypto/crypto_skcipher.ko] undefined! >> ERROR: modpost: "memcpy" [crypto/seqiv.ko] undefined! Are these from ARC build or otherwise ? Thx, -Vineet
Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote: > On 27.03.24 16:21, Peter Xu wrote: >> On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote: >> >> I'm not sure what config you tried there; as I am doing some build tests >> recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could >> avoid a lot of issues, I think it's due to libc missing. But maybe not the >> case there. > > CCin Arnd; I use some of his compiler chains, others from Fedora directly. For > example for alpha and arc, the Fedora gcc is "13.2.1". > > But there is other stuff like (arc): > > ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid': > ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of > function 'write_aux_reg' [-Werro > r=implicit-function-declaration] > 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE); >| ^ Seems to be missing an #include of soc/arc/aux.h, but I can't tell when this first broke without bisecting. > or (alpha) > > WARNING: modpost: "saved_config" [vmlinux] is COMMON symbol > ERROR: modpost: "memcpy" [fs/reiserfs/reiserfs.ko] undefined! > ERROR: modpost: "memcpy" [fs/nfs/nfs.ko] undefined! > ERROR: modpost: "memcpy" [fs/nfs/nfsv3.ko] undefined! > ERROR: modpost: "memcpy" [fs/nfsd/nfsd.ko] undefined! > ERROR: modpost: "memcpy" [fs/lockd/lockd.ko] undefined! > ERROR: modpost: "memcpy" [crypto/crypto.ko] undefined! > ERROR: modpost: "memcpy" [crypto/crypto_algapi.ko] undefined! > ERROR: modpost: "memcpy" [crypto/aead.ko] undefined! > ERROR: modpost: "memcpy" [crypto/crypto_skcipher.ko] undefined! > ERROR: modpost: "memcpy" [crypto/seqiv.ko] undefined! Al did a series to fix various build problems on alpha, see https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/log/?h=work.alpha Not sure if he still has to send them to Matt, or if Matt just needs to apply them. I also have some alpha patches that I should send upstream. Arnd
Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
On 27.03.24 16:46, Ryan Roberts wrote:
Some of them look like mm-unstable issue, For example, arm64 fails with
CC arch/arm64/mm/extable.o
In file included from ./include/linux/hugetlb.h:828,
from security/commoncap.c:19:
./arch/arm64/include/asm/hugetlb.h:25:34: error: redefinition of
'arch_clear_hugetlb_flags'
25 | #define arch_clear_hugetlb_flags arch_clear_hugetlb_flags
| ^~~~
./include/linux/hugetlb.h:840:20: note: in expansion of macro
'arch_clear_hugetlb_flags'
840 | static inline void arch_clear_hugetlb_flags(struct folio *folio) { }
| ^~~~
./arch/arm64/include/asm/hugetlb.h:21:20: note: previous definition of
'arch_clear_hugetlb_flags' with t
ype 'void(struct folio *)'
21 | static inline void arch_clear_hugetlb_flags(struct folio *folio)
| ^~~~
In file included from ./include/linux/hugetlb.h:828,
from mm/filemap.c:37:
./arch/arm64/include/asm/hugetlb.h:25:34: error: redefinition of
'arch_clear_hugetlb_flags'
25 | #define arch_clear_hugetlb_flags arch_clear_hugetlb_flags
| ^~~~
./include/linux/hugetlb.h:840:20: note: in expansion of macro
'arch_clear_hugetlb_flags'
840 | static inline void arch_clear_hugetlb_flags(struct folio *folio) { }
| ^~~~
./arch/arm64/include/asm/hugetlb.h:21:20: note: previous definition of
'arch_clear_hugetlb_flags' with type 'void(struct folio *)'
21 | static inline void arch_clear_hugetlb_flags(struct folio *folio)
see: https://lore.kernel.org/linux-mm/zgqvnkgdldkwh...@casper.infradead.org/
Yes, besides the other failures I see (odd targets), I was expecting
that someone else noticed that already :) thanks!
--
Cheers,
David / dhildenb
Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
>
> Some of them look like mm-unstable issue, For example, arm64 fails with
>
> CC arch/arm64/mm/extable.o
> In file included from ./include/linux/hugetlb.h:828,
> from security/commoncap.c:19:
> ./arch/arm64/include/asm/hugetlb.h:25:34: error: redefinition of
> 'arch_clear_hugetlb_flags'
> 25 | #define arch_clear_hugetlb_flags arch_clear_hugetlb_flags
> | ^~~~
> ./include/linux/hugetlb.h:840:20: note: in expansion of macro
> 'arch_clear_hugetlb_flags'
> 840 | static inline void arch_clear_hugetlb_flags(struct folio *folio) { }
> | ^~~~
> ./arch/arm64/include/asm/hugetlb.h:21:20: note: previous definition of
> 'arch_clear_hugetlb_flags' with t
> ype 'void(struct folio *)'
> 21 | static inline void arch_clear_hugetlb_flags(struct folio *folio)
> | ^~~~
> In file included from ./include/linux/hugetlb.h:828,
> from mm/filemap.c:37:
> ./arch/arm64/include/asm/hugetlb.h:25:34: error: redefinition of
> 'arch_clear_hugetlb_flags'
> 25 | #define arch_clear_hugetlb_flags arch_clear_hugetlb_flags
> | ^~~~
> ./include/linux/hugetlb.h:840:20: note: in expansion of macro
> 'arch_clear_hugetlb_flags'
> 840 | static inline void arch_clear_hugetlb_flags(struct folio *folio) { }
> | ^~~~
> ./arch/arm64/include/asm/hugetlb.h:21:20: note: previous definition of
> 'arch_clear_hugetlb_flags' with type 'void(struct folio *)'
> 21 | static inline void arch_clear_hugetlb_flags(struct folio *folio)
see: https://lore.kernel.org/linux-mm/zgqvnkgdldkwh...@casper.infradead.org/
Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
On 27.03.24 16:21, Peter Xu wrote:
On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote:
Some cleanups around function names, comments and the config option of
"GUP-fast" -- GUP without "lock" safety belts on.
With this cleanup it's easy to judge which functions are GUP-fast specific.
We now consistently call it "GUP-fast", avoiding mixing it with "fast GUP",
"lockless", or simply "gup" (which I always considered confusing in the
ode).
So the magic now happens in functions that contain "gup_fast", whereby
gup_fast() is the entry point into that magic. Comments consistently
reference either "GUP-fast" or "gup_fast()".
Based on mm-unstable from today. I won't CC arch maintainers, but only
arch mailing lists, to reduce noise.
Tested on x86_64, cross compiled on a bunch of archs, whereby some of them
don't properly even compile on mm-unstable anymore in my usual setup
(alpha, arc, parisc64, sh) ... maybe the cross compilers are outdated,
but there are no new ones around. Hm.
I'm not sure what config you tried there; as I am doing some build tests
recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could
avoid a lot of issues, I think it's due to libc missing. But maybe not the
case there.
CCin Arnd; I use some of his compiler chains, others from Fedora directly. For
example for alpha and arc, the Fedora gcc is "13.2.1".
I compile quite some targets, usually with defconfig. From my compile script:
# COMPILER NAME ARCH CROSS_COMPILE CONFIG(if different from defconfig)
compile_gcc "alpha" "alpha" "alpha-linux-gnu-"
compile_gcc "arc" "arc" "arc-linux-gnu-"
compile_gcc "arm" "arm" "arm-linux-gnu-" "axm55xx_defconfig"
compile_gcc "arm-nommu" "arm" "arm-linux-gnu-" "imxrt_defconfig"
compile_gcc "arm64" "arm64" "aarch64-linux-gnu-"
compile_gcc "csky" "csky"
"../cross/gcc-13.2.0-nolibc/csky-linux/bin/csky-linux-"
compile_gcc "loongarch" "loongarch"
"../cross/gcc-13.2.0-nolibc/loongarch64-linux/bin/loongarch64-linux-"
compile_gcc "m68k-nommu" "m68k" "m68k-linux-gnu-" "amcore_defconfig"
compile_gcc "m68k-sun3" "m68k" "m68k-linux-gnu-" "sun3_defconfig"
compile_gcc "m68k-coldfire" "m68k" "m68k-linux-gnu-" "m5475evb_defconfig"
compile_gcc "m68k-virt" "m68k" "m68k-linux-gnu-" "virt_defconfig"
compile_gcc "microblaze" "microblaze" "microblaze-linux-gnu-"
compile_gcc "mips64" "mips" "mips64-linux-gnu-" "bigsur_defconfig"
compile_gcc "mips32-xpa" "mips" "mips64-linux-gnu-" "maltaup_xpa_defconfig"
compile_gcc "mips32-alchemy" "mips" "mips64-linux-gnu-" "gpr_defconfig"
compile_gcc "mips32" "mips" "mips64-linux-gnu-"
compile_gcc "nios2" "nios2" "nios2-linux-gnu-" "3c120_defconfig"
compile_gcc "openrisc" "openrisc" "../cross/gcc-13.2.0-nolibc/or1k-linux/bin/or1k-linux-"
"virt_defconfig"
compile_gcc "parisc32" "parisc" "hppa-linux-gnu-" "generic-32bit_defconfig"
compile_gcc "parisc64" "parisc" "hppa64-linux-gnu-" "generic-64bit_defconfig"
compile_gcc "riscv32" "riscv" "riscv64-linux-gnu-" "32-bit.config"
compile_gcc "riscv64" "riscv" "riscv64-linux-gnu-" "64-bit.config"
compile_gcc "riscv64-nommu" "riscv" "riscv64-linux-gnu-" "nommu_virt_defconfig"
compile_gcc "s390x" "s390" "s390x-linux-gnu-"
compile_gcc "sh" "sh" "../cross/gcc-13.2.0-nolibc/sh4-linux/bin/sh4-linux-"
compile_gcc "sparc32" "sparc" "../cross/gcc-13.2.0-nolibc/sparc-linux/bin/sparc-linux-"
"sparc32_defconfig"
compile_gcc "sparc64" "sparc"
"../cross/gcc-13.2.0-nolibc/sparc64-linux/bin/sparc64-linux-" "sparc64_defconfig"
compile_gcc "uml64" "um" "" "x86_64_defconfig"
compile_gcc "x86" "x86" "" "i386_defconfig"
compile_gcc "x86-pae" "x86" "" "i386_defconfig"
compile_gcc "x86_64" "x86" ""
compile_gcc "xtensa" "xtensa" "../cross/gcc-13.2.0-nolibc/xtensa-linux/bin/xtensa-linux-"
"virt_defconfig"
compile_gcc "powernv" "powerpc"
"../cross/gcc-13.2.0-nolibc/powerpc64-linux/bin/powerpc64-linux-" "powernv_defconfig"
compile_gcc "pseries" "powerpc"
"../cross/gcc-13.2.0-nolibc/powerpc64-linux/bin/powerpc64-linux-" "pseries_defconfig"
Some of them look like mm-unstable issue, For example, arm64 fails with
CC arch/arm64/mm/extable.o
In file included from ./include/linux/hugetlb.h:828,
from security/commoncap.c:19:
./arch/arm64/include/asm/hugetlb.h:25:34: error: redefinition of
'arch_clear_hugetlb_flags'
25 | #define arch_clear_hugetlb_flags arch_clear_hugetlb_flags
| ^~~~
./include/linux/hugetlb.h:840:20: note: in expansion of macro
'arch_clear_hugetlb_flags'
840 | static inline void arch_clear_hugetlb_flags(struct folio *folio) { }
|^~~~
./arch/arm64/include/asm/hugetlb.h:21:20: note: previous definition of
'arch_clear_hugetlb_flags' with t
ype 'void(struct folio *)'
21 | static inline void arch_clear_hugetlb_flags(struct folio *folio)
|^~~~
In file included from ./include/linux/hugetlb.h:828,
from mm/filemap.c:37:
Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote: > Some cleanups around function names, comments and the config option of > "GUP-fast" -- GUP without "lock" safety belts on. > > With this cleanup it's easy to judge which functions are GUP-fast specific. > We now consistently call it "GUP-fast", avoiding mixing it with "fast GUP", > "lockless", or simply "gup" (which I always considered confusing in the > ode). > > So the magic now happens in functions that contain "gup_fast", whereby > gup_fast() is the entry point into that magic. Comments consistently > reference either "GUP-fast" or "gup_fast()". > > Based on mm-unstable from today. I won't CC arch maintainers, but only > arch mailing lists, to reduce noise. > > Tested on x86_64, cross compiled on a bunch of archs, whereby some of them > don't properly even compile on mm-unstable anymore in my usual setup > (alpha, arc, parisc64, sh) ... maybe the cross compilers are outdated, > but there are no new ones around. Hm. I'm not sure what config you tried there; as I am doing some build tests recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could avoid a lot of issues, I think it's due to libc missing. But maybe not the case there. The series makes sense to me, the naming is confusing. Btw, thanks for posting this as RFC. This definitely has a conflict with the other gup series that I had; I'll post v4 of that shortly. -- Peter Xu
