Message-ID: <3922460a-4d01-4ecb-b8c5-7c57fd46f3fd@redhat.com>
Date: Wed, 27 Mar 2024 16:39:45 +0100
From: David Hildenbrand <david@...hat.com>
To: Peter Xu <peterx@...hat.com>
Cc: linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
 Mike Rapoport <rppt@...nel.org>, Jason Gunthorpe <jgg@...dia.com>,
 John Hubbard <jhubbard@...dia.com>, linux-arm-kernel@...ts.infradead.org,
 loongarch@...ts.linux.dev, linux-mips@...r.kernel.org,
 linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
 linux-sh@...r.kernel.org, linux-mm@...ck.org,
 linux-perf-users@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 x86@...nel.org, Arnd Bergmann <arnd@...db.de>,
 Ryan Roberts <ryan.roberts@....com>
Subject: 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:
/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

Powered by blists - more mailing lists