Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
From: David Hildenbrand
Date: Wed Mar 27 2024 - 11:42:41 EST
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:
/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)
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);
| ^~~~~~~~~~~~~
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!
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.
Yes, I will rebase on top of that!
--
Cheers,
David / dhildenb